On 7/21/2025 9:45 PM, Vishal Annapurve wrote:
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.
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.
