On Wed, Oct 15, 2025 at 03:48:38PM -0700, Sean Christopherson wrote:
On Wed, Oct 15, 2025, Gregory Price wrote:
why is __kvm_gmem_get_policy using mpol_shared_policy_lookup() instead of get_vma_policy()
With the disclaimer that I haven't followed the gory details of this series super closely, my understanding is...
Because the VMA is a means to an end, and we want the policy to persist even if the VMA goes away.
Ah, you know, now that i've taken a close look, I can see that you've essentially modeled this after ipc/shm.c | mm/shmem.c pattern.
What's had me scratching my chin is that shm/shmem already has a mempolicy pattern which ends up using folio_alloc_mpol() where the relationship is
tmpfs: sb_info->mpol = default set by user create_file: inode inherits copy of sb_info->mpol fault: mpol = shmem_get_pgoff_policy(info, index, order, &ilx); folio = folio_alloc_mpol(gfp, order, mpol, ilx, numa_node_id())
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
This makes sense, sorry for the noise. Have been tearing apart mempolicy lately and I'm disliking the general odor coming off it as a whole. I had been poking at adding mempolicy support to filemap and you got there first. Overall I think there are still other problems with mempolicy, but this all looks fine as-is.
~Gregory