On Mon, Jul 21, 2025 at 3:21 PM Sean Christopherson <seanjc@xxxxxxxxxx> wrote: > > On Mon, Jul 21, 2025, Vishal Annapurve wrote: > > On Mon, Jul 21, 2025 at 10:29 AM Sean Christopherson <seanjc@xxxxxxxxxx> wrote: > > > > > > > > > > > > > 2) KVM fetches shared faults through userspace page tables and not > > > > > > guest_memfd directly. > > > > > > > > > > This is also irrelevant. KVM _already_ supports resolving shared faults through > > > > > userspace page tables. That support won't go away as KVM will always need/want > > > > > to support mapping VM_IO and/or VM_PFNMAP memory into the guest (even for TDX). > > > > As a combination of [1] and [2], I believe we are saying that for > > memslots backed by mappable guest_memfd files, KVM will always serve > > both shared/private faults using kvm_gmem_get_pfn(). > > No, KVM can't guarantee that with taking and holding mmap_lock across hva_to_pfn(), > and as I mentioned earlier in the thread, that's a non-starter for me. I think what you mean is that if KVM wants to enforce the behavior that VMAs passed by the userspace are backed by the same guest_memfd file as passed in the memslot then KVM will need to hold mmap_lock across hva_to_pfn() to verify that. What I understand from the implementation of [1] & [2], all guest faults on a memslot backed by mappable guest_memfd will pass the fault_from_gmem() check and so will be routed to guest_memfd i.e. hva_to_pfn path is skipped for any guest faults. If userspace passes in VMA mapped by a different guest_memfd file then the guest and userspace will have a different view of the memory for shared faults. [1] https://lore.kernel.org/kvm/20250717162731.446579-10-tabba@xxxxxxxxxx/ [2] https://lore.kernel.org/kvm/20250717162731.446579-14-tabba@xxxxxxxxxx/ > > For a memslot without a valid slot->gmem.file, slot->userspace_addr will be used > to resolve faults and access guest memory. By design, KVM has no knowledge of > what lies behind userspace_addr (arm64 and other architectures peek at the VMA, > but x86 does not). So we can't say that mmap()'d guest_memfd instance will *only* > go through kvm_gmem_get_pfn(). > >
