On Mon, Dec 15, 2025 at 03:51:51PM -0500, Peter Xu wrote: > v1: https://lore.kernel.org/r/[email protected] > v2: https://lore.kernel.org/r/[email protected] > > v3: > - Collect R-bs from Xiaoyao > - Rebased to 10.2-rc3; no dependency needed now, as those got merged > - Reorder patches, touch up commit messages or comments on in-place misuse > - Added patch "kvm: Provide explicit error for kvm_create_guest_memfd()" > [Xiaoyao] > - Added one patch for renaming machine_require_guest_memfd() [Xiaoyao] > - Added one patch for renaming memory_region_init_ram_guest_memfd() [Xiaoyao] > > =========8<=========== > > This series allows QEMU to consume init-shared guest-memfd to be a common > memory backend. Before this series, guest-memfd was only used in CoCo and > the fds will be created implicitly whenever CoCo environment is detected. > When used in init-shared mode, the guest-memfd will be specified in the > command lines directly just like other types of memory backends. > > In the current patchset, I reused the memory-backend-memfd object, rather > than creating a new type of object. After all, guest-memfd (at least from > userspace POV) works similarly like a memfd, except that it was tailored > for VM's use case. > > This approach so far also does not involve gmem bindings to KVM instances, > hence it is not prone to issues when the same chunk of RAM will be attached > to more than one KVM memslots. > > Now, instead of using a normal memfd backend using: > > -object memory-backend-memfd,id=ID,size=SIZE,share=on > > One can also boot a VM with guest-memfd: > > -object memory-backend-memfd,id=ID,size=SIZE,share=on,guest-memfd=on
Hi Peter, I'm working on enabling support for this, as well as enabling in-place conversion support for confidential VMs[1]. In my series I added a dedicated memory-backend-guest-memfd to handle using mmapable guest_memfd to back normal VMs (and confidential VMs with in-place conversion enabled on top). Xiaoyao mentioned we had some overlap and potential inter-dependencies between our series so I took some notes on the differences which I've included at the bottom of this email... But at a high-level I think this series is further along in implementing guest_memfd for normal VMs, and I would plan to just mostly rebase my in-place conversion patches on top of your series. However I think it would be a good idea to go with a dedicated memory-backend-guest-memfd for reasons I outlined in my notes, so maybe this needs to be discussed more. I also saw you were open to having someone pick up these patches if you don't think you'll have a chance to get to them near-term, so I'd be happy to pick them up if that's preferable. Thanks! -Mike [1] https://lore.kernel.org/qemu-devel/[email protected]/ Comparisons to the above patchset: [PATCH v3 01/12] kvm: Decouple memory attribute check from kvm_guest_memfd_supported - similar to: [PATCH 01/12] accel/kvm: Decouple guest_memfd checks from memory attribute checks - to allow mmap case, both defer error handling to ram_block_add() + RAM_GUEST_MEMFD path - pros: adds nice kvm_private_memory_attribute_supported() helper - cons: my patch checks/prints error via kvm_create_guest_memfd(), which makes it a more re-usable error since ram_block_add() isn't the only caller. - IMO, I think we should merge the pros of your patch into my similar patch and add your Co-developed-by, but also fine to keep yours as-is and deal with anything else needed as a follow-up patch [PATCH v3 02/12] kvm: Detect guest-memfd flags supported - similar to the kvm_supported_guest_memfd_flags / kvm_create_guest_memfd_shared() additions that are part of: [02/12] hostmem: Introduce dedicated memory backend for guest_memfd - This patch could be treated as a common dependency of the above and I can drop the corresponding changes from my patch [PATCH v3 03/12] kvm: Provide explicit error for kvm_create_guest_memfd() - Keep as-is [PATCH v3 04/12] ramblock: Rename guest_memfd to guest_memfd_private - Keep as-is [PATCH v3 05/12] memory: Rename RAM_GUEST_MEMFD to RAM_GUEST_MEMFD_PRIVATE - Keep as-is [PATCH v3 06/12] memory: Rename memory_region_has_guest_memfd() to *_private() - Keep as-is [PATCH v3 07/12] hostmem: Rename guest_memfd to guest_memfd_private - Keep as-is [PATCH v3 08/12] hostmem: Support fully shared guest memfd to back a VM - alternative to: [02/12] hostmem: Introduce dedicated memory backend for guest_memfd - pros: re-uses infrastructure from hostmem-memfd - pros: less command-line changes vs. dedicated hostmem-guest-memfd (less libvirt changes?) - cons: less flexibility vs. a dedicated backend - cons: more risk of memfd vs guest_memfd behavior/options diverging over time and having less commonality (e.g. if hugetlb has special options we wouldn't need to muddy the existing documentation for normal memfds or introduce alternative options alongside) - IMO, a clean state patch only requires ~90 lines of potentially-duplicate code, and that's offset to some degree by needing less special-casing throughout hostmem-memfd.c (e.g. this patchset adds 55 lines on top), and it seems worthwhile given some of the advanced use-cases planned around guest_memfd (hugetlb, DAX-like functionality, and persisting userspace across kexec) that might require special handling/options for very different use-cases than normal memfds. [PATCH v3 09/12] machine: Rename machine_require_guest_memfd() to *_private() - Keep as-is - (all these renames are a nice cleanup/prep and will help a lot with making in-place conversion handling more readable) [PATCH v3 10/12] memory: Rename memory_region_init_ram_guest_memfd() to *_private() - Keep as-is - (all these renames are a nice cleanup/prep and will help a lot with making in-place conversion handling more readable) [PATCH v3 11/12] tests/migration-test: Support guest-memfd init shared mem type - Keep as-is [PATCH v3 12/12] tests/migration-test: Add a precopy test for guest-memfd - Keep as-is > > The init-shared guest-memfd relies on almost the latest linux, as the > mmap() support just landed v6.18-rc2. When run it on an older qemu, we'll > see errors like: > > qemu-system-x86_64: KVM does not support guest_memfd > > One thing to mention is live migration is by default supported, however > postcopy is still currently not supported. The postcopy support will have > some kernel dependency work to be merged in Linux first. > > Thanks, > > Peter Xu (11): > kvm: Detect guest-memfd flags supported > kvm: Provide explicit error for kvm_create_guest_memfd() > ramblock: Rename guest_memfd to guest_memfd_private > memory: Rename RAM_GUEST_MEMFD to RAM_GUEST_MEMFD_PRIVATE > memory: Rename memory_region_has_guest_memfd() to *_private() > hostmem: Rename guest_memfd to guest_memfd_private > hostmem: Support fully shared guest memfd to back a VM > machine: Rename machine_require_guest_memfd() to *_private() > memory: Rename memory_region_init_ram_guest_memfd() to *_private() > tests/migration-test: Support guest-memfd init shared mem type > tests/migration-test: Add a precopy test for guest-memfd > > Xiaoyao Li (1): > kvm: Decouple memory attribute check from kvm_guest_memfd_supported > > qapi/qom.json | 6 ++- > include/hw/boards.h | 2 +- > include/system/hostmem.h | 2 +- > include/system/kvm.h | 1 + > include/system/memory.h | 27 ++++++------ > include/system/ram_addr.h | 2 +- > include/system/ramblock.h | 7 +++- > tests/qtest/migration/framework.h | 4 ++ > accel/kvm/kvm-all.c | 33 ++++++++++++--- > accel/stubs/kvm-stub.c | 6 +++ > backends/hostmem-file.c | 2 +- > backends/hostmem-memfd.c | 55 +++++++++++++++++++++--- > backends/hostmem-ram.c | 2 +- > backends/hostmem-shm.c | 2 +- > backends/hostmem.c | 2 +- > backends/igvm.c | 4 +- > hw/core/machine.c | 2 +- > hw/i386/pc.c | 6 +-- > hw/i386/pc_sysfw.c | 8 ++-- > hw/i386/x86-common.c | 8 ++-- > system/memory.c | 17 ++++---- > system/physmem.c | 37 ++++++++++------- > target/i386/kvm/kvm.c | 3 +- > tests/qtest/migration/framework.c | 60 +++++++++++++++++++++++++++ > tests/qtest/migration/precopy-tests.c | 12 ++++++ > 25 files changed, 239 insertions(+), 71 deletions(-) > > -- > 2.50.1 > >
