Alexey Kardashevskiy <[email protected]> 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? > 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
