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/[email protected] > > > The final series where we added mempolicy support should be: > > https://lore.kernel.org/linux-mm/[email protected]/ > > (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
