Re: [PATCH v3 00/12] KVM/hostmem: Support init-shared guest-memfd as VM backends

[Peter Xu <peterx@redhat.com>]

On Tue, Jun 02, 2026 at 05:02:29PM -0500, Michael Roth wrote:
> On Mon, Dec 15, 2025 at 03:51:51PM -0500, Peter Xu wrote:
> > v1: https://lore.kernel.org/r/20251023185913.2923322-1-peterx@redhat.com
> > v2: https://lore.kernel.org/r/20251119172913.577392-1-peterx@redhat.com
> > 
> > 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,

Hi, Michael,

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

To Xiaoyao: thanks for linking these works, and also thanks for answering
other question I raised in the separate thread.

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

To me, it was just natural when working on that to reuse memfd backend,
because conceptually they're really the same: I guess guest-memfd is named
as guest-memfd (not guest-special-fd etc.) also because of that.

I don't have a strong feeling here, hostmem-memfd.c is tiny so duplicating
isn't a major concern even if so.  It's just that I don't yet see when gmem
will become special.

Say, all of the features that memfd provides can easily be applied to
guest-memfd either now or at some point later:

  - hugetlb/hugetlbsize being one of them already, I believe we almost know
    1G will happen to gmem soon
  - seal: I don't see why we can't seal a gmemfd too.. maybe it'll come, in
    general the whole seal concept can apply to gmem too.
  - cpr support on memfd (or anything about live update in the future to
    happen on gmem): I believe gmem also want it..

IIUC it's a matter of if we expect future property of guest-memfd that will
stop applying to memfd anymore?

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

Sure!  Indeed I don't have bandwidth to keep working on this one in the
near future. Please feel free to pick whatever needed into your series.

Thanks,

> 
> Thanks!
> 
> -Mike
> 
> [1] https://lore.kernel.org/qemu-devel/20260528000416.8161-1-michael.roth@amd.com/
> 
> 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
> > 
> > 
> 

-- 
Peter Xu