Re: [PATCH] KVM: guest_memfd: fix NUMA interleave index double-counting

[Sean Christopherson]

On Tue, Jun 09, 2026, Michael S. Tsirkin wrote:
> On Tue, Jun 09, 2026 at 09:31:29AM -0700, Sean Christopherson wrote:
> > On Wed, 03 Jun 2026 11:57:33 -0400, Michael S. Tsirkin wrote:
> > > kvm_gmem_get_policy() sets *ilx to the full page offset
> > > (vm_pgoff + vma offset).  But get_vma_policy() adds the page
> > > offset on top of *ilx, so the offset is counted twice.  This
> > > causes NUMA interleaving to skip nodes: for order-0 pages the
> > > effective index jumps by 2 for each consecutive page.
> > > 
> > > The get_policy vm_op should return only a per-file bias in *ilx
> > > (like shmem_get_policy does with inode->i_ino), letting
> > > get_vma_policy() add the page-offset component.
> > > 
> > > [...]
> > 
> > Applied to kvm-x86 gmem, with a heavily massaged changelog to explicitly spell
> > out that ilx == interleave index, and to try and explain the role of the index
> > (it wasn't at all obvious to me why using the inode number was "correct").
> > 
> > Thanks!
> > 
> > [1/1] KVM: guest_memfd: fix NUMA interleave index double-counting
> >       https://github.com/kvm-x86/linux/commit/48dbe4732198
> 
> Thanks!
> 
> Sean, what is your take on interleaving for guest_memfd?
> 
> To the best of my understanding:
> 
> Right now IIUC kvm calls __filemap_get_folio_mpol which in turn does not pass
> the index to filemap_alloc_folio. That uses NO_INTERLEAVE_INDEX, so
> MPOL_INTERLEAVE uses the task's global counter - effectively
> unpredictable placement. This looks like an oversight (the index was
> available but never threaded down), but it's been shipping since 6.19.
> 
> Should we fix it to use the file offset instead? Or GPA? And if so,
> should that be the default or does userspace need a way to opt out of
> NO_INTERLEAVE_INDEX?

Honestly, I wouldn't bother fixing the issue for guest_memfd.  If someone wants
to pursue a fix for a different use case, then we can piggyback that effort, but
I don't think it's worth the effort for guest_memfd.

In practice, I doubt anyone will run guest_memfd with MPOL_INTERLEAVE.  Maybe
when we get to the point where guest_memfd is usable for "normal" VMs?  But even,
splattering a single guest memslot across multiple NUMA nodes is all bug guaranteed
to provide suboptimal performance.  E.g. if the user cares about NUMA policy, I
would expect a given guest_memfd instance to be bound to a specific node.