On Wed, Jan 28, 2026 at 01:47:50PM -0800, Ackerley Tng wrote: > 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)?
I think they should have a memslot, shouldn't they? I imagine creating a memslot from a FD and the FD can be memfd, guestmemfd, dmabuf, etc, etc ? > 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. I don't know where you want to store them in KVM long term, but they need to come from the dmabuf itself (probably via a struct p2pdma_provider) and currently it is OK to assume all DMABUFs are uncachable MMIO that is safe for the VM to convert into "write combining" (eg Normal-NC on ARM) Jason
