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

[Peter Xu <peterx@redhat.com>]

On Thu, Jun 04, 2026 at 05:36:42PM -0500, Michael Roth wrote:
> > IIUC it's a matter of if we expect future property of guest-memfd that will
> > stop applying to memfd anymore?
> 
> Yah, I think that's the main thing to consider. There's a few things in the
> pipeline where the options associated with guest_memfd might diverage
> quite a bit from memfd:

Thanks for all these contexts.  I'll throw some random questions below,
some of them may not be directly related to the current discussion, but
please bare with me.

> 
>   - hugetlb: yes, these could potentially use the same options memfd
>     uses, and I'm guessing that will end up being the case, but one
>     large gap there is that shared memory is always split to 4K, which
>     we've accepted for now, but if you consider use-cases like DPDK
>     there can still be major performance bottlenecks that would drive
>     us to try to enable larger mappings for the shared ranges, and then
>     we'd end up with guest-memfd-specific parameters intermix with
>     normal memfd options, and our related documentation would need to
>     covers these differences case by case

The first thing I thought about is mTHP and how it can also be similarly
applied to normal memfd (now, or in the future, that I'm not sure).

Before that..  shouldn't the whole concept of private mem / gmem about
reducing the area of mapping the host (including dpdk, if we're talking
about things like OpenVswitch)?  Can you roughly describe how huge mapping
is expected to be allowed in such case?  Does it mean the guest driver
should also be aware to allocate huge continuous physical mem for DMA only?

>   - DAX-like stuff: there are some proposals for making device memory
>     available to use as private guest memory, and since 'guest-memfd'
>     is generally responsible for managing private memory, it will
>     likely end up being extended to handle this at some point. One
>     proposal/PoC[1] would involve at least needing additional options
>     for the /dev/dax path, but there have also been discussions about
>     having a general notion of custom allocators that can be plugged
>     into guest_memfd, and some of these might have overlapping options
>     WRT things like hugepages/etc. But at a high-level, DAX would map
>     more to memory-backend-file than memory-backend-memfd, so we'd
>     already be crossing up some wires there.

I have no deep understanding on this, but IIUC we used to stick with
memory-backend-file for dax.  Why switch to memory-backend-guest-memfd?
Are we still exposing a dax via a file path ultimately, even with CoCo?

Note, here I want to differenciate two concepts: QEMU interfacing and
kernel/KVM interfacing.  I mean, I have a gut feeling that for coco dax we
could still stick with memory-backend-file, even if internally we can still
use new KVM ioctls to set them up: there's no rule to say only
memory-backend-guest-memfd can use the KVM ioctl.  IMHO they're different
stories, and here I'm focused more on the QEMU interfacing that we're
discussing here.

IMHO for QEMU's interfacing, any memory-backend should play one solo role
which is to point to QEMU (as a hypervisor) a backing store for some piece
of resource that can be used as guest memory backend.  It doesn't need to
have any implication on how we implement that backend internally.

>   - live update: there's work[2] on enabling preservation of confidential
>     guest memory across kexec by preserving it through guest_memfd. This
>     one is still a bit mind-blowing to me but I could see us needing
>     some additional options here that would really make no sense for
>     memfd.

Could you elaborate what kind of parameter you would expect?

I'm not sure if you have investigated QEMU's CPR approach, now memfd
backend is really the core of supporting such infrastructure, where fds can
be persisted.  For live update, it'll be persisted across kexec and kernel
switchover.  For CPR, it actually also works when with cpr-reboot with its
own tricky way to persist memory.

In general, what I want to say is, I really think they should play the same
in term of live update case too: if we need to register some fd for
persistency, we need to register gmem, kvm, but also memfd if some of them
are attached to the current VM, right?

>   - directmap removal: these[3] patches allow a new guest_memfd flag to
>     be set to unmap guest_memfd pages from kernel directmap to help
>     mitigate speculative attacks, probably would involve a new option
>     as well that wouldn't be applicable to normal memfds

Now the question is, do we want to remove directmap for "some" memory
backend, or do we want to remove it per-VM?

This is another thing I want to make sure we're on the same page: I want to
make sure we don't introduce per-VM setup for memory backends.

Say, "init-shared" or "in-place CoCo", what should we use for one gmem fd?
IMHO it shouldn't be a parameter in the memory-backend.  It should be a
parameter for the -machine or some similar per-vm setup, which will apply
to all gmemfd across the current VM.

My understanding is directmap removal is similar in this case, which seems
to be a per-VM (rather than per-memory-backend) attribute?  We can still
operate on that per-memory-backend, but then it'll be internally, the
backends need to understand the VM setup and do things properly, IMHO.

> 
> It could also end up that even memory-backend-guest-memfd is too
> generic, and that some of these would involve a more specialized memory
> backend where may they can share a common base class for some of the
> core guest_memfd stuff but otherwise be separate backends with their
> own specific options. So to me, starting off building up
> memory-backend-memfd seems like a potential misstep, whereas we don't
> really lose much to start with a clean slate.
> 
> [1] DAX: https://lwn.net/ml/all/20260423170219.281618-1-dave.jiang@intel.com/
> [2] LUO: https://lore.kernel.org/all/cover.1779080766.git.tarunsahu@google.com/#r
> [3] directmap removal: https://lore.kernel.org/kvm/20260317141031.514-1-kalyazin@amazon.com/
> 
> > 
> > > 
> > > 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.
> 
> Ok, sounds good, I'll pick these up for my next posting and incorporate
> any changes/comments that might still be pending at that time.
> 
> Thanks for getting things to this stage!

Thanks for picking it up!  Juraj in our team may have some future
exploration on gmem over 1G for postcopy on init-shared, so it's great the
code is moving closer to that direction.

Thanks,

-- 
Peter Xu