> From: Alexey Kardashevskiy <aik@xxxxxxx> > Sent: Tuesday, August 27, 2024 10:28 AM > > On 26/8/24 18:39, Tian, Kevin wrote: > > +Jason/David > > > >> From: Alexey Kardashevskiy <aik@xxxxxxx> > >> Sent: Friday, August 23, 2024 9:21 PM > >> > >> 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 > > Forgot [1]? [1] https://lore.kernel.org/kvm/20240620143406.GJ2494510@xxxxxxxxxx/ > > > that the IOMMU page table for private memory will be managed by > > the secure world i.e. the KVM path. > > > > Obviously the work here confirms that it doesn't hold for SEV-TIO > > which still expects the host to manage the IOMMU page table. > > > > btw going down this path it's clearer to extend the MAP_DMA > > uAPI to accept {gmemfd, offset} than adding a callback to KVM. > > Thanks for the comment, makes sense, this should make the interface > cleaner. It was just a bit messy (but doable nevertheless) at the time > to push this new mapping flag/type all the way down to > pfn_reader_user_pin: > > iommufd_ioas_map -> iopt_map_user_pages -> iopt_map_pages -> > iopt_fill_domains_pages -> iopt_area_fill_domains -> pfn_reader_first -> > pfn_reader_next -> pfn_reader_fill_span -> pfn_reader_user_pin > > > Thanks, > > -- > Alexey
