On Tue, Jul 22, 2025 at 7:35 AM Sean Christopherson <seanjc@xxxxxxxxxx> wrote: > > 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. Ok, yeah. I completely misjudged the usecase that Xiaoyao brought up. You are right. These are two different scenarios that I mixed up: 1) Userspace brings a non-mappable guest_memfd to back guest private memory (passed as guest_memfd field in the KVM_USERSPACE_MEMORY_REGION2) : This is the legacy case that needs separate memory to back userspace_addr. As Sean mentioned, userspace should be able to bring VMAs backed by any mappable files including guest_memfd except mappable guest_memfd is not supported for SNP/TDX VMs today, that support will come in stage2. KVM doesn't need to enforce anything here as we can be sure that VMAs and unmappable guest_memfd are pointing to different physical ranges. 2) Userspace brings a mappable guest_memfd to back guest private memory (passed as guest_memfd field in the KVM_USERSPACE_MEMORY_REGION2): KVM will always fault in all guest faults via guest_memfd so if userspace brings in VMAs that point to different physical memory then there would be a discrepancy between what guest and userspace/KVM (going through HVAs) sees for shared memory ranges. I am not sure if KVM needs to enforce anything here, IMO it's the problem between userspace and guest to resolve. One thing we may need to resolve is that invalidations of KVM EPT/NPT tables for shared ranges should be triggered only by guest_memfd invalidations (This is something we need to resolve when conversions will be supported on guest_memfd i.e. not for this series, but the next stage).
