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. 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@xxxxxxxxxx/ > [2] https://lore.kernel.org/kvm/20250717162731.446579-14-tabba@xxxxxxxxxx/ > > > > > > > > > > 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.
