Re: [PATCH v10 09/41] KVM: guest_memfd: Filter both shared and private when invalidating
From: Xiaoyao Li <hidden>
Date: 2026-08-27 04:34:29
Also in:
kvm, linux-doc, linux-kselftest, linux-mm, linux-trace-kernel, lkml
On 8/26/2026 9:53 PM, Sean Christopherson wrote: <snip>
quoted
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.
quoted hunk ↗ jump to hunk
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@google.com/ (local)
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.