Re: [RFC PATCH v1 05/37] KVM: guest_memfd: Wire up kvm_get_memory_attributes() to per-gmem attributes
From: Ackerley Tng <hidden>
Date: 2026-01-28 21:47:53
Also in:
cgroups, kvm, linux-fsdevel, linux-kselftest, linux-mm, linux-trace-kernel, lkml
Alexey Kardashevskiy [off-list ref] writes:
[...snip...]
Thanks for bringing this up!
I am trying to make it work with TEE-IO where fd of VFIO MMIO is a dmabuf fd while the rest (guest RAM) is gmemfd. The above suggests that if there is gmemfd - then the memory attributes are handled by gmemfd which is... expected?
I think this is not expected. IIUC MMIO guest physical addresses don't have an associated memslot, but if you managed to get to that line in kvm_gmem_get_memory_attributes(), then there is an associated memslot (slot != NULL)? Either way, guest_memfd shouldn't store attributes for guest physical addresses that don't belong to some guest_memfd memslot. I think we need a broader discussion for this on where to store memory attributes for MMIO addresses. I think we should at least have line of sight to storing memory attributes for MMIO addresses, in case we want to design something else, since we're putting vm_memory_attributes on a deprecation path with this series. Sean, what do you think? Alexey, shall we discuss this at either the upcoming PUCK or guest_memfd biweekly session?
quoted hunk ↗ jump to hunk
The problem at hand is that kvm_mmu_faultin_pfn() fails at "if (fault->is_private != kvm_mem_is_private(kvm, fault->gfn))" and marking MMIO as private using kvm_vm_ioctl_set_mem_attributes() does not work as kvm_gmem_get_memory_attributes() fails on dmabuf fds. I worked around this like below but wonder what is the proper way? Thanks,@@ -768,13 +768,13 @@ unsigned long kvm_gmem_get_memory_attributes(struct kvm *kvm, gfn_t gfn) */ if (!slot) return 0; CLASS(gmem_get_file, file)(slot); if (!file) - return false; + return kvm_get_vm_memory_attributes(kvm, gfn); /* * Don't take the filemap invalidation lock, as temporarily acquiring * that lock wouldn't provide any meaningful protection. The caller * _must_ protect consumption of private vs. shared by checking * mmu_invalidate_retry_gfn() under mmu_lock. --Alexey