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...] >>>
