On Mon, Jul 21, 2025 at 5:22 AM Xiaoyao Li <xiaoyao.li@xxxxxxxxx> 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. 2) KVM fetches shared faults through userspace page tables and not guest_memfd directly. I don't see value in trying to go out of way to support such a usecase. > > SO my question is do we want to support such case?
