On Mon, Aug 04, 2025 at 08:02:23AM +0530, Alexey Kardashevskiy wrote: > I ended up exporting the guestmemfd's kvm_gmem_get_folio() for gfn->pfn and its fd a bit differently in iommufd - "no extra referencing": > https://github.com/AMDESE/linux-kvm/commit/f1ebd358327f026f413f8d3d64d46decfd6ab7f6 This patch needs to explain how the lifecylce works and why the IOMMU can't UAF the memory. I think it cannot really work as shown without more things like an invalidation callback. IOW you need to define for how long the return result of guest_memfd_get_pfn() is valid for. > > I was kind of thinking it would be nice to have a guestmemfd mode that > > was "pinned", meaning the memory is allocated and remains almost > > always mapped into the TSM's page tables automatically. VFIO using > > guests would set things this way. > > Yeah while doing the above, I was wondering if I want to pass the fd > type when DMA-mapping from an fd or "detect" it as I do in the above > commit or have some iommufd_fdmap_ops in this fd saying "(no) > pinning needed" (or make this a flag of IOMMU_IOAS_MAP_FILE). It should be autodetected. Since this is unique behavior for guestmemfd it is fine to start there.. > btw in the AMD case, here it does not matter as much if it is > private or shared, I map everything and let RMP and the VM deal with > the permissions. Thanks, I think ARM would like to do this as well. Hence my suggestion that guestmemfd could just have unchanging 1G PFNs and all shared/private changes have no impact on iommufd. If so likely all this needs is an invalidation callback from guestmemfd to iommufd to revoke on ftruncate. Jason
