On Mon, Jul 21, 2025, Xiaoyao Li wrote: > On 7/21/2025 10:42 PM, Sean Christopherson wrote: > > > > 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. > > > > > > Why do you want such a usecase to work? > > > > I'm guessing Xiaoyao was asking an honest question in response to finding a > > perceived flaw when trying to get this all working in QEMU. > > I'm not sure if it is an flaw. Such usecase is not supported is just > anti-intuition to me. > > > > If kvm allows mappable guest_memfd files for TDX VMs without > > > conversion support, userspace will be able to use those for backing > > > > s/able/unable? > > I think vishal meant "able", because ... > > > > private memory unless: > > > 1) KVM checks at binding time if the guest_memfd passed during memslot > > > creation is not a mappable one and doesn't enforce "not mappable" > > > requirement for TDX VMs at creation time. > > > > Xiaoyao's question is about "just for shared memory", so this is irrelevant for > > the question at hand. > > ... if we allow gmem mmap for TDX, KVM needs to ensure the mmapable gmem > should only be passed via userspace_addr. IOW, KVM needs to forbid userspace > from passing the mmap'able guest_memfd to > kvm_userspace_memory_region2.guest_memfd. Because it allows userspace to > access the private mmeory. TDX support needs to be gated (and is gated) on private vs. shared being tracked in guest_memfd. And that restriction should be (and is) reflected in KVM_CAP_GUEST_MEMFD_MMAP when invoked on a VM (versus on /dev/kvm). > > > > 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). > > > > > 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.
