Re: [PATCH v15 14/21] KVM: x86: Enable guest_memfd mmap for default VM type

[Sean Christopherson <seanjc@google.com>]

On Mon, Jul 21, 2025, Vishal Annapurve wrote:
> On Mon, Jul 21, 2025 at 10:29 AM Sean Christopherson <seanjc@google.com> 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.

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().


> And I think the same story will be carried over when we get the stage2 i.e.
> mmap+conversion support.
> 
> [1] https://lore.kernel.org/kvm/20250717162731.446579-10-tabba@google.com/
> [2] https://lore.kernel.org/kvm/20250717162731.446579-14-tabba@google.com/
> 
> > > >
> > > > > I don't see value in trying to go out of way to support such a usecase.
> > > >
> > > > But if/when KVM gains support for tracking shared vs. private in guest_memfd
> > > > itself, i.e. when TDX _does_ support mmap() on guest_memfd, KVM won't have to go
> > > > out of its to support using guest_memfd for the @userspace_addr backing store.
> > > > Unless I'm missing something, the only thing needed to "support" this scenario is:
> > >
> > > As above, we need 1) mentioned by Vishal as well, to prevent userspace from
> > > passing mmapable guest_memfd to serve as private memory.
> >
> > Ya, I'm talking specifically about what the world will look like once KVM tracks
> > private vs. shared in guest_memfd.  I'm not in any way advocating we do this
> > right now.
> 
> I think we should generally strive to go towards single memory backing
> for all the scenarios, unless there is a real world usecase that can't
> do without dual memory backing (We should think hard before committing
> to supporting it).
> 
> Dual memory backing was just a stopgap we needed until the *right*
> solution came along.

I don't think anyone is suggesting otherwise.  I'm just pointing out that what
Xiaoyao is trying to do should Just Work once KVM allows creating mmap()-friendly
guest_memfd instances for TDX.