On 7/21/2025 8:22 PM, Xiaoyao Li 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.
one more findings.
I tested with QEMU by creating normal (non-private) memory with mmapable
guest memfd, and enforcily passing the fd of the gmem to struct
kvm_userspace_memory_region2 when QEMU sets up memory region.
It hits the kvm_gmem_bind() error since QEMU tries to back different GPA
region with the same gmem.
So, the question is do we want to allow the multi-binding for
shared-only gmem?
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.
SO my question is do we want to support such case?
