Re: [PATCH v10 09/41] KVM: guest_memfd: Filter both shared and private when invalidating

[Sean Christopherson]

On Wed, Aug 26, 2026, Ackerley Tng wrote:
> Xiaoyao Li <xiaoyao.li@xxxxxxxxx> writes:
> 
> > On 8/26/2026 2:55 AM, Sean Christopherson wrote:
> >> On Tue, Aug 25, 2026, Michael Roth wrote:
> >>> On Wed, Aug 26, 2026 at 12:13:47AM +0800, Xiaoyao Li wrote:
> >>>> On 8/20/2026 9:32 AM, Sean Christopherson wrote:
> >>>>> And vice versa, a PUNCH_HOLE on a SHARED gmem (if userspace is
> >>>>> using an INIT_SHARED gmem for the shared branch of a memslot) could invalidate the
> >>>>> PRIVATE mappings (of a different gmem instance).
> >>>>
> >>>> I'm wondering now how this could happen.
> >>>>
> >>>> the requirement for PUNCH_HOLE on gmem to trigger mapping invalidation is
> >>>> the gmem is bound with the memslot. But how can a memslot bound with two
> >>>> gmem instances?
> >>>
> >>> I think this is for when userspace uses an mmap'able guest_memfd instance
> >>> to handle shared memory, and a 'normal' guest_memfd instance for private
> >>> memory. Each instance is bound to the same memslot/GPA range, and
> >>> KVM_SET_MEMORY_ATTRIBUTES handles switching between the 2.
> >
> > What I didn't figure out is exactly how the two gmem instances are bound
> > to the same memslot.
> >
> > The case I can imagine is
> >
> > 1. create gmem1 with GUEST_MEMFD_FLAG_MMAP and
> > GUEST_MEMFD_FLAG_INIT_SHARED, and get fd1. mmap the returned fd1 to get
> > a hva.
> >
> > 2. create gmem2 to get a fd2.
> >
> > 3. call KVM_SET_USER_MEMORY_REGION2 with KVM_MEM_GUEST_MEMFD flag. Pass
> > the @hva from 1) to 'userspace_addr' field and pass the gmem fd2 to
> > 'guest_memfd' field.
> >
> > However, with this case, only gmem2 is bound to the memslot while gmem1
> > is not. Following PUNCH_HOLE on gmem1 doesn't invalidate any mappings
> > because the f->bindings of it is empty.
> >
> > Do I miss anything?

Oh, I misread your question.  You were specifically asking about a PUNCH_HOLE in
a SHARED gmem instance over-invalidating PRIVATE mappings.  You're right, that
wouldn't happen because the invalidations would come in via mmu_notifiers, not
from KVM.

> I think Xiaoyao is right about this, the "vice versa" part is wrong,

Ya.

> Is this just a case of user error? That with gmem_in_place_conversion,
> userspace should not use userspace_addr from something other than the
> gmem for the same memslot?

Yes.  It's not just invalidations that will go sideways, KVM accesses to guest
memory won't hit the same physical page as actual guest accesses.

Huh.  But that isn't strictly guaranteed, because userspace could bind to a
memslot that isn't configured with GUEST_MEMFD_FLAG_MMAP, in which case SHARED
faults will go through the VMA, not kvm_mmu_faultin_pfn_gmem().  It's a bit early
in the morning, but off the top of my head, I can't think of any reason we need
to support such a setup.  If userspace really, really wants to use a separate
mapping, they could DELETE+CREATE an equivalent memslot without the guest_memfd
file descriptor.

So I think we should do this?

diff --git a/virt/kvm/guest_memfd.c b/virt/kvm/guest_memfd.c
index 9c2d52bdf25e..86f53e53a136 100644
--- a/virt/kvm/guest_memfd.c
+++ b/virt/kvm/guest_memfd.c
@@ -1013,7 +1013,7 @@ int kvm_gmem_bind(struct kvm *kvm, struct kvm_memory_slot *slot,
 	 */
 	WRITE_ONCE(slot->gmem.file, file);
 	slot->gmem.pgoff = start;
-	if (kvm_gmem_supports_mmap(inode))
+	if (gmem_in_place_conversion || kvm_gmem_supports_mmap(inode))
 		slot->flags |= KVM_MEMSLOT_GMEM_ONLY;
 
 	xa_store_range(&f->bindings, start, end - 1, slot, GFP_KERNEL);

Regardless, the key aspect of all this is that in-place conversion is brand new
functionality, so we don't have to ensure backwards compatibility.