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

Michael Roth posted 12 patches 2 weeks, 4 days ago
Patches applied successfully (tree, apply log)
git fetch https://github.com/patchew-project/qemu tags/patchew/20260908133151.836685-1-michael.roth@amd.com
Maintainers: Paolo Bonzini <pbonzini@redhat.com>, David Hildenbrand <david@kernel.org>, Igor Mammedov <imammedo@redhat.com>, Gerd Hoffmann <kraxel@redhat.com>, Stefano Garzarella <sgarzare@redhat.com>, Ani Sinha <anisinha@redhat.com>, "Philippe Mathieu-Daudé" <philmd@oss.qualcomm.com>, Zhao Liu <zhao1.liu@intel.com>, "Michael S. Tsirkin" <mst@redhat.com>, Richard Henderson <richard.henderson@linaro.org>, Peter Xu <peterx@redhat.com>, "Daniel P. Berrangé" <berrange@redhat.com>, Eric Blake <eblake@redhat.com>, Markus Armbruster <armbru@redhat.com>, Marcelo Tosatti <mtosatti@redhat.com>, Fabiano Rosas <farosas@suse.de>, Laurent Vivier <lvivier@redhat.com>
There is a newer version of this series
accel/kvm/kvm-all.c                   | 38 ++++++++++++++++++----
accel/stubs/kvm-stub.c                |  6 ++++
backends/hostmem-file.c               |  2 +-
backends/hostmem-memfd.c              | 60 +++++++++++++++++++++++++++++++----
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 ++---
include/hw/core/boards.h              |  2 +-
include/system/hostmem.h              |  2 +-
include/system/kvm.h                  |  1 +
include/system/memory.h               | 27 ++++++++--------
include/system/ramblock.h             |  9 ++++--
qapi/qom.json                         |  6 +++-
system/memory.c                       | 14 ++++----
system/physmem.c                      | 51 +++++++++++++++++------------
target/i386/kvm/kvm.c                 |  3 +-
tests/qtest/migration/framework.c     | 60 +++++++++++++++++++++++++++++++++++
tests/qtest/migration/framework.h     |  4 +++
tests/qtest/migration/precopy-tests.c |  9 ++++++
24 files changed, 252 insertions(+), 76 deletions(-)
[PATCH v5 00/12] KVM/hostmem: Support init-shared guest-memfd as VM backends
Posted by Michael Roth 2 weeks, 4 days ago
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: https://lore.kernel.org/r/20251215205203.1185099-1-peterx@redhat.com/
v4: https://lore.kernel.org/qemu-devel/20260812201938.198915-1-michael.roth@amd.com/
v5:
- Fix error handling for 'hugetlb' when guest-memfd=on (Daniel, Peter)
- Default to 'seal' option being allowed/on for guest-memfd=on since
  it already satisfies the documented semantics (Peter)
- Don't explicitly set a placeholder URI for qtest/migration-test
  as the code now relies on NULL for this path (Peter)
- Clarify rationale for checking for kvm_enabled() in 
  kvm_create_guest_memfd() (Philippe, Peter)

This patchset is also available at:

  https://github.com/amdese/qemu/commits/gmem-shared-mem-v5

and is based on top of qemu master (99e54ab5e7)


OVERVIEW
========

(cover letter shamelessly adapted from Peter's prior postings)

Recent kernels allow guest_memfd to be initialized with an 'init-shared'
flag that will default to allocating normal/non-private memory that can be
used to back non-confidential VMs.

This allows QEMU to make use of these init-shared guest_memfd instances via
a common memory backend that's usable for either provide a common memory
backend.

On the QEMU side, before this series, guest_memfd was only used for private
guest memory (and thus only applied to confidential VMs), and the guest_memfd
FDs would be created implicitly whenever a confidential environment was
detected/specified.

With this series, users can now explicitly configure QEMU to use guest_memfd
for non-private memory; thus, it can be used for non-confidential
VMs. It also has implications for confidential VMs, since with this series an
init-shared guest_memfd instance can now be specified for the shared memory
while the internally-allocated guest_memfd continues to be used for private
memory. This same infrastructure will also be used as the base for enabling
in-place conversion for confidential VMs, where these separate shared/private
paths will be modified to act on the same underlying guest_memfd instance and
use a unified pool of shared/private memory.


IMPLEMENTATION
==============

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. While there is potential that new guest_memfd features
may eventually necessitate introducing a dedicated guest_memfd memory
backend object, for now the memory-backend-memfd object is a good fit for
the current feature set.

This will also make it easier when in-place conversion comes around, since
confidential VMs typically already use memory-backend-memfd for their shared
memory, so by also making using that approach to specify the guest_memfd
backend for in-place conversion the command-line syntax remains similar, and
even allow choosing between memfd vs. guest_memfd to be handled automatically
based on whether or not we're dealing with a Confidential VM with in-place
conversion enabled.

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

The init-shared guest-memfd relies on a recent kernel (6.18+). When run it on
an older qemu, you'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,

Mike


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

 accel/kvm/kvm-all.c                   | 38 ++++++++++++++++++----
 accel/stubs/kvm-stub.c                |  6 ++++
 backends/hostmem-file.c               |  2 +-
 backends/hostmem-memfd.c              | 60 +++++++++++++++++++++++++++++++----
 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 ++---
 include/hw/core/boards.h              |  2 +-
 include/system/hostmem.h              |  2 +-
 include/system/kvm.h                  |  1 +
 include/system/memory.h               | 27 ++++++++--------
 include/system/ramblock.h             |  9 ++++--
 qapi/qom.json                         |  6 +++-
 system/memory.c                       | 14 ++++----
 system/physmem.c                      | 51 +++++++++++++++++------------
 target/i386/kvm/kvm.c                 |  3 +-
 tests/qtest/migration/framework.c     | 60 +++++++++++++++++++++++++++++++++++
 tests/qtest/migration/framework.h     |  4 +++
 tests/qtest/migration/precopy-tests.c |  9 ++++++
 24 files changed, 252 insertions(+), 76 deletions(-)
Re: [PATCH v5 00/12] KVM/hostmem: Support init-shared guest-memfd as VM backends
Posted by David Hildenbrand 2 weeks, 2 days ago
On 9/8/26 15:30, Michael Roth 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: https://lore.kernel.org/r/20251215205203.1185099-1-peterx@redhat.com/
> v4: https://lore.kernel.org/qemu-devel/20260812201938.198915-1-michael.roth@amd.com/
> v5:
> - Fix error handling for 'hugetlb' when guest-memfd=on (Daniel, Peter)
> - Default to 'seal' option being allowed/on for guest-memfd=on since
>   it already satisfies the documented semantics (Peter)
> - Don't explicitly set a placeholder URI for qtest/migration-test
>   as the code now relies on NULL for this path (Peter)
> - Clarify rationale for checking for kvm_enabled() in 
>   kvm_create_guest_memfd() (Philippe, Peter)
> 
> This patchset is also available at:
> 
>   https://github.com/amdese/qemu/commits/gmem-shared-mem-v5
> 
> and is based on top of qemu master (99e54ab5e7)
> 
> 
> OVERVIEW
> ========
> 
> (cover letter shamelessly adapted from Peter's prior postings)
> 
> Recent kernels allow guest_memfd to be initialized with an 'init-shared'
> flag that will default to allocating normal/non-private memory that can be
> used to back non-confidential VMs.
> 
> This allows QEMU to make use of these init-shared guest_memfd instances via
> a common memory backend that's usable for either provide a common memory
> backend.
> 
> On the QEMU side, before this series, guest_memfd was only used for private
> guest memory (and thus only applied to confidential VMs), and the guest_memfd
> FDs would be created implicitly whenever a confidential environment was
> detected/specified.
> 
> With this series, users can now explicitly configure QEMU to use guest_memfd
> for non-private memory; thus, it can be used for non-confidential
> VMs. It also has implications for confidential VMs, since with this series an
> init-shared guest_memfd instance can now be specified for the shared memory
> while the internally-allocated guest_memfd continues to be used for private
> memory. This same infrastructure will also be used as the base for enabling
> in-place conversion for confidential VMs, where these separate shared/private
> paths will be modified to act on the same underlying guest_memfd instance and
> use a unified pool of shared/private memory.
> 
> 
> IMPLEMENTATION
> ==============
> 
> 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. While there is potential that new guest_memfd features
> may eventually necessitate introducing a dedicated guest_memfd memory
> backend object, for now the memory-backend-memfd object is a good fit for
> the current feature set.
> 
> This will also make it easier when in-place conversion comes around, since
> confidential VMs typically already use memory-backend-memfd for their shared
> memory, so by also making using that approach to specify the guest_memfd
> backend for in-place conversion the command-line syntax remains similar, and
> even allow choosing between memfd vs. guest_memfd to be handled automatically
> based on whether or not we're dealing with a Confidential VM with in-place
> conversion enabled.
> 
> 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
> 
> The init-shared guest-memfd relies on a recent kernel (6.18+). When run it on
> an older qemu, you'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.

All makes sense to me!
-- 
Cheers,

David