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

[Xiaoyao Li <xiaoyao.li@intel.com>]

On 7/21/2025 9:45 PM, Vishal Annapurve wrote:
> On Mon, Jul 21, 2025 at 5:22 AM Xiaoyao Li <xiaoyao.li@intel.com> wrote:
>>
>> On 7/18/2025 12:27 AM, Fuad Tabba wrote:
>>> +/*
>>> + * CoCo VMs with hardware support that use guest_memfd only for backing private
>>> + * memory, e.g., TDX, cannot use guest_memfd with userspace mapping enabled.
>>> + */
>>> +#define kvm_arch_supports_gmem_mmap(kvm)             \
>>> +     (IS_ENABLED(CONFIG_KVM_GMEM_SUPPORTS_MMAP) &&   \
>>> +      (kvm)->arch.vm_type == KVM_X86_DEFAULT_VM)
>>
>> I want to share the findings when I do the POC to enable gmem mmap in QEMU.
>>
>> 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.
>>
>> Since the gmem is mmapable, QEMU can pass the userspace addr got from
>> mmap() on gmem fd to kvm_userspace_memory_region(2).userspace_addr. It
>> works well for non-coco VMs on x86.
>>
>> Then it seems feasible to use gmem with mmap for the shared memory of
>> TDX, and an additional gmem without mmap for the private memory. i.e.,
>> For struct kvm_userspace_memory_region, the @userspace_addr is passed
>> with the uaddr returned from gmem0 with mmap, while @guest_memfd is
>> passed with another gmem1 fd without mmap.
>>
>> 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?
> 
> If kvm allows mappable guest_memfd files for TDX VMs without
> conversion support, userspace will be able to use those for backing
> 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.

yes, this is the additional change required.

> 2) KVM fetches shared faults through userspace page tables and not
> guest_memfd directly.

current KVM supports it already.

And as I described above,  current userspace can just mmap the gmem and 
pass the gotten addr to userspace_addr without passing guest_memfd, to 
force KVM to fetch through userspace page tables.

So if we want KVM to fetch page from guest memfd directly, should we add 
something in KVM to enforce it?

> I don't see value in trying to go out of way to support such a usecase.

 From my perspective, it's intuitive to think about this usecase when I 
tried to enable gmem mmap in QEMU. It seems a little strange that 
mmap'ed gmem can only serve as normal memory for non-CoCo VMs.

If KVM mandates any gmem must be passed via 
kvm_userspace_memory_region2.guest_memfd, no matter it's mmap'ed or not, 
it would make more sense (to me) to not support such usecase, since 
there is only one guest_memfd field in struct kvm_userspace_memory_region2.

At last, I just put it on the table, so people can be aware of it and 
make the call to support it or not. Either is OK to me.