Re: [PATCH 0/5] KVM: guest_memfd: bind backing memory to a NUMA node

[Gregory Price <gourry@gourry.net>]

On Thu, Sep 10, 2026 at 04:05:36PM +0200, David Hildenbrand (Arm) wrote:
> On 9/10/26 15:40, Gregory Price wrote:
> > On Thu, Sep 10, 2026 at 01:30:04PM +0200, David Hildenbrand (Arm) wrote:
> >> On 9/2/26 21:46, Gregory Price wrote:
> >>> guest_memfd allocates its folios through a per-inode shared mempolicy.
> >>>
> >>> Today that policy can only be set after the fact, with mbind() on a host
> >>> mmap of the fd. That requires the fd to be mappable, and it cannot reach
> >>> folios that are only ever guest-faulted. Neither holds for a
> >>> non-mappable (confidential) guest_memfd.
> >>
> >> That looks like an investment into a mechanism we will soon consider legacy, so
> >> I am not convinced this is the right approach?
> >>
> > 
> > Hm, I think i've missed recent work in this space / this context.
> > Any suggested reading here? Don't want to eat too much of your time.
> 
> So the big development happening right now is in-place conversion (having shared
> and private pages managed in guest_memfd):
> 
> https://lore.kernel.org/r/20260830-gmem-inplace-conversion-v12-0-85e5fd25252a@google.com
> 
> 
> The final series where we added mempolicy support should be:
> 
> https://lore.kernel.org/linux-mm/20250827175247.83322-2-shivankg@amd.com/
> 
> (I think you are aware of that, you commented on some)
> 
> See my other reply regarding the use of GUEST_MEMFD_FLAG_MMAP on private-only
> guest_memfd.
> 

Ah yes, i do remember this series.  In fact...

https://lore.kernel.org/linux-mm/aPD-dbl5KWNSHu5R@gourry-fedora-PF4VCD3F/

```
So this inode mempolicy in guest_memfd is really acting more as a the
filesystem-default mempolicy, which you want to survive even if userland
never maps the memory/unmaps the memory.

So the relationship is more like

guest_memfd -> creates fd/inode <- copies task mempolicy (if set)
  vm:  allocates memory via filemap_get_folio_mpol()
  userland mmap(fd):
  	creates new inode<->vma mapping
	vma->mpol = kvm_gmem_get_policy()
	calls to set/get_policy/mbind go through kvm_gmem
```

And quick skim of in-place conversion (wow that's dense) 

```
  #define KVM_MEMORY_ATTRIBUTE_PRIVATE           (1ULL << 3)

  Set attributes for a range of offsets within a guest_memfd to
  KVM_MEMORY_ATTRIBUTE_PRIVATE to limit the specified guest_memfd backed
  memory range for guest use. Even if KVM_CAP_GUEST_MEMFD_MMAP is
  supported, after a successful call to set KVM_MEMORY_ATTRIBUTE_PRIVATE,
  the requested range will not be mappable into host userspace and will
  only be mappable by the guest.
```

I guess the thought here would be something like...

1. create guest memfd
2. mmap(fd)               -> prior to full guest setup
3. mbind(buf)             -> shared policy hits the inode
4. munmap(buf)            -> policy is NOT reaped
5. set ATTRIBUTE_PRIVATE
6. no longer user mappable

That doesn't seem unreasonable

~Gregory