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

[David Hildenbrand <david@kernel.org>]

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