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

[Xiaoyao Li]

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?  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.

> 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/
>   	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.