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

[Sean Christopherson]

On Thu, Aug 27, 2026, Xiaoyao Li wrote:
> On 8/26/2026 9:53 PM, Sean Christopherson wrote:
> <snip>
> > > 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.
> 
> Side topic.
> 
> If KVM enforces KVM_MEMSLOT_GMEM_ONLY when gmem_in_place_conversion is true
> like below proposal, should we update KVM's guest memory accessors to access
> gmem directly?

No, because routing KVM accesses through uaccess means we just have to ensure
PRIVATE memory isn't mapped into userspace, which we already have to do anyways.

Now, that doesn't preclude future work from optimizing certain flows to avoid
GUP, or to harden KVM in other ways.  But as a first step, bypassing uaccess is
actively dangerous.

> If still use the existing code of accessing userspace_addr of the memslot, I
> think KVM needs to document clearly that when
> KVM_CAP_GUEST_MEMFD_MEMORY_ATTRIBUTES is enumerated, if configuring the
> guest_memfd for a memslot, the userspace_addr passed in needs to be the
> mmaped address of the guest_memfd.

Ya.

> > 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;
> 
> I like this idea. It makes gmem_in_place_conversion a step closer to what
> its name implies, though in-place conversion is not truly 100%
> guaranteed[*].
> 
> [*] https://lore.kernel.org/all/akUbz_kJvYulaboo@xxxxxxxxxx