On Mon, Aug 26, 2024 at 09:30:24AM -0300, Jason Gunthorpe wrote: > On Mon, Aug 26, 2024 at 08:39:25AM +0000, Tian, Kevin wrote: > > > IOMMUFD calls get_user_pages() for every mapping which will allocate > > > shared memory instead of using private memory managed by the KVM and > > > MEMFD. > > > > > > Add support for IOMMUFD fd to the VFIO KVM device's KVM_DEV_VFIO_FILE > > > API > > > similar to already existing VFIO device and VFIO group fds. > > > This addition registers the KVM in IOMMUFD with a callback to get a pfn > > > for guest private memory for mapping it later in the IOMMU. > > > No callback for free as it is generic folio_put() for now. > > > > > > The aforementioned callback uses uptr to calculate the offset into > > > the KVM memory slot and find private backing pfn, copies > > > kvm_gmem_get_pfn() pretty much. > > > > > > This relies on private pages to be pinned beforehand. > > > > > > > There was a related discussion [1] which leans toward the conclusion > > that the IOMMU page table for private memory will be managed by > > the secure world i.e. the KVM path. > > It is still effectively true, AMD's design has duplication, the RMP > table has the mappings to validate GPA and that is all managed in the > secure world. > > They just want another copy of that information in the unsecure world > in the form of page tables :\ > > > btw going down this path it's clearer to extend the MAP_DMA > > uAPI to accept {gmemfd, offset} than adding a callback to KVM. > > Yes, we want a DMA MAP from memfd sort of API in general. So it should > go directly to guest memfd with no kvm entanglement. A uAPI like ioctl(MAP_DMA, gmemfd, offset, iova) still means userspace takes control of the IOMMU mapping in the unsecure world. But as mentioned, the unsecure world mapping is just a "copy" and has no generic meaning without the CoCo-VM context. Seems no need for userspace to repeat the "copy" for IOMMU. Maybe userspace could just find a way to link the KVM context to IOMMU at the first place, then let KVM & IOMMU directly negotiate the mapping at runtime. Thanks, Yilun > > Jason >