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]?
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
