On Mon, Jul 21, 2025, Vishal Annapurve wrote: > 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. No, I'm talking about the case where userspace creates a memslot *without* KVM_MEM_GUEST_MEMFD, but with userspace_addr pointing at a mmap()'d guest_memfd instance. That is the scenario Xiaoyao brought up: : Actually, QEMU can use gmem with mmap support as the normal memory even : without passing the gmem fd to kvm_userspace_memory_region2.guest_memfd : on KVM_SET_USER_MEMORY_REGION2. : : ... : : However, it fails actually, because the kvm_arch_suports_gmem_mmap() : returns false for TDX VMs, which means userspace cannot allocate gmem : with mmap just for shared memory for TDX.
