From: Michael Roth <michael.roth@amd.com>
To: <qemu-devel@nongnu.org>
Cc: <jmarcin@redhat.com>, <david@kernel.org>, <pbonzini@redhat.com>,
<chenyi.qiang@intel.com>, <peterx@redhat.com>, <farosas@suse.de>,
<aik@amd.com>, <xiaoyao.li@intel.com>
Subject: [PATCH v4 00/12] KVM/hostmem: Support init-shared guest-memfd as VM backends
Date: Wed, 12 Aug 2026 15:16:38 -0500 [thread overview]
Message-ID: <20260812201938.198915-1-michael.roth@amd.com> (raw)
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:
- Picked up v3 series from Peter Xu and rebased on 11.1.0
- Collected pending Reviewed-by's
- Per-patch changes:
[01/12] Fix blank space (Xiaoyao)
Fix commit message typos
[02/12] Drop duplicated error-handling for capability checks
[05/12] Fix up commit message, disambigurate "in-place" terminology (Xiaoyao)
[07/12] Fix up commit message, disambigurate "in-place" terminology (Xiaoyao)
[08/12] Disallow 'seal' and 'hugetlb' options based on guest-memfd=on
Fix minor typo in comment
[11/12] Fix up typo in g_test_skip() reason
Pending: Move kvm_guest_memfd_init_shared_supported() to
migration-util.c (Fabiano)
This patchset is also available at:
https://github.com/amdese/qemu/commits/gmem-shared-mem-v4
and is based on top of v11.1.0
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.
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
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,
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
next reply other threads:[~2026-08-12 20:22 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-12 20:16 Michael Roth [this message]
2026-08-12 20:16 ` [PATCH v4 01/12] kvm: Decouple memory attribute check from kvm_guest_memfd_supported Michael Roth
2026-08-12 20:16 ` [PATCH v4 02/12] kvm: Detect guest-memfd flags supported Michael Roth
2026-08-12 20:16 ` [PATCH v4 03/12] kvm: Provide explicit error for kvm_create_guest_memfd() Michael Roth
2026-08-12 20:16 ` [PATCH v4 04/12] ramblock: Rename guest_memfd to guest_memfd_private Michael Roth
2026-08-12 20:16 ` [PATCH v4 05/12] memory: Rename RAM_GUEST_MEMFD to RAM_GUEST_MEMFD_PRIVATE Michael Roth
2026-08-12 20:16 ` [PATCH v4 06/12] memory: Rename memory_region_has_guest_memfd() to *_private() Michael Roth
2026-08-12 20:16 ` [PATCH v4 07/12] hostmem: Rename guest_memfd to guest_memfd_private Michael Roth
2026-08-12 20:16 ` [PATCH v4 08/12] hostmem: Support fully shared guest memfd to back a VM Michael Roth
2026-08-12 20:16 ` [PATCH v4 09/12] machine: Rename machine_require_guest_memfd() to *_private() Michael Roth
2026-08-12 20:16 ` [PATCH v4 10/12] memory: Rename memory_region_init_ram_guest_memfd() " Michael Roth
2026-08-12 20:16 ` [PATCH v4 11/12] tests/migration-test: Support guest-memfd init shared mem type Michael Roth
2026-08-12 20:16 ` [PATCH v4 12/12] tests/migration-test: Add a precopy test for guest-memfd Michael Roth
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260812201938.198915-1-michael.roth@amd.com \
--to=michael.roth@amd.com \
--cc=aik@amd.com \
--cc=chenyi.qiang@intel.com \
--cc=david@kernel.org \
--cc=farosas@suse.de \
--cc=jmarcin@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peterx@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=xiaoyao.li@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.