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