Re: [PATCH v4 11/11] KVM: selftests: Add guest_memfd_preservation_test

Tarun Sahu <[email protected]> writes:

> Ackerley Tng <[email protected]> writes:
>
>> Tarun Sahu <[email protected]> writes:
>>
>>> Add guest_memfd_preservation_test to verify that KVM VM state and guest
>>> memory backed by guest_memfd are preserved across a kexec reboot via Live
>>> Update Orchestrator (LUO).
>>>
>>> This test includes multiple tests
>>> - (A) Test to preserve non-guest_memfd, non-memfd which must fail (/dev/null)
>>> - (B) Test to preserve guest_memfd with no INIT_SHARED flag which must fail
>>> - (C) Test to allocate the guest_memfd memory after preservation because
>>>   preservation makes the guest_memfd frozen. Which must fail as well.
>>> - (D) Test to verify guest_memfd with INIT_SHARED flag preservation across
>>>   kexec: Below is the details of stages in this test.
>>>
>>
>> I think we should split this into multiple patches, where each patch
>> introduces 1 test.
>
> Got it. I will split them. I thought that this test already spawn a VM
> and other test can just reuse the same VM.

From upstream hypervisor liveupdate meeting, I realized you meant to be
same file but saperate commits. Sound good to me. I will take care of that.

>
>>
>>>
>>> [...snip...]
>>>
>>> +++ b/tools/testing/selftests/kvm/guest_memfd_preservation_test.c
>>> @@ -0,0 +1,357 @@
>>> +// SPDX-License-Identifier: GPL-2.0
>>> +/*
>>> + * Copyright (C) 2026, Google LLC.
>>> + *
>>> + * Author: Tarun Sahu <[email protected]>
>>> + *
>>> + * Test for VM and guest_memfd preservation across kexec (Live Update) via LUO.
>>> + *
>>> + * NOTE: This is a MANUAL test and is excluded from automated CI/testing
>>> + * frameworks because Stage 1 daemonizes into the background to pin resources
>>> + * and requires a human operator to manually trigger kexec before Stage 2
>>> + * is executed. Running Stage 1 automatically would leak the background daemon
>>> + * and cause CI runners to falsely interpret it as a passed test.
>>> + *
>>
>> Usually there aren't many printfs in tests, but since this is a MANUAL
>> test, maybe that's ok?
>>
>> Would like to know what Sean thinks of this, and printfs in general.
>>
>>>
>>> [...snip...]
>>>