Re: [PATCH 8/8] hostmem: Support in-place guest memfd to back a VM

[Peter Xu <peterx@redhat.com>]

On Mon, Oct 27, 2025 at 01:24:25PM +0800, Xiaoyao Li wrote:
> I was not authorized to do the QEMU upstream of gmem mmap support inside the
> company. So please keep your series and I'm happy to help review it and make
> it upstreamed.

Thank you, I'll definitely copy you for all future posts.

> 
> > > 
> > > Third, the intended usage of gmem with mmap from KVM/kernel's perspective is
> > > userspace configures the meomry slot by passing the gmem fd to @guest_memfd
> > > and @guest_memfd of struct kvm_userspace_memory_region2 instead of passing
> > > the user address returned by mmap of the fd to @userspace_addr return mmap()
> > > as this patch does. Surely the usage of this path works. But when QEMU is
> > > going to support in-place conversion of gmem, we has to pass the
> > > @guest_memfd.
> > > Well, this is no issue now and we can handle it in the future when needed.
> > 
> > Yes, that's something the private guest-memfd would need.  For completely
> > shared guest-memfd, IIUC we will use a lot of different code paths, the
> > goal is to make old APIs work not only for KVM_SET_USER_MEMORY_REGION, but
> > for all the rest modules like vhost-kernel, vhost-user, and so on.
> 
> And if pass the @guest_memfd, we will need to handle the issue of aliased:
> https://lore.kernel.org/all/aH-0MdNJbH19Mhm3@google.com/

Note that it's intentional here I reuse userspace_addr, and I have no plan
to support gmem binding with fully shared gmems yet because my current
purpose doesn't need it (I want to ultimately enable postcopy 1G, hence I
want to move away from hugetlbfs but use gmem).

Hence as discussed, my goal is to make gmem work exactly like memfd here
and exactly like before, supporting all kinds of kernel modules.  GUP must
work, hence HVA is needed.

So yes, I was aware of the issue discussed there on SMM aliasing, because I
also hit it at that time when testing against the very 1st kernel patchset
from Ackerley on supporting 1G.

That's also something I want to avoid when reusing userspace_addr rather
than using KVM_SET_USER_MEMORY_REGION2.

I plan to leave any form of kvm gmem binding support to others.  Likely
this new interface is not needed by either the old approach (where
ramblocks need to duplicate memory consumption like right now), or when
in-place conversion is ready (hence no double mem consumption issue,
however guest-memfd as fd will still be privately created).

Thanks,

-- 
Peter Xu