On Mon, Apr 13, 2026 at 10:58:20AM +0200, Christian König wrote:
On 2/18/26 01:11, Jason Gunthorpe wrote:
This type is required by iommufd and kvm as dmabuf importers.
Due to sensitivity about abusing physical addresses, restrict importers by using EXPORT_SYMBOL_FOR_MODULES(). Only iommufd can implement an importer, the kernel module loader will enforce this.
Allow anything to implement an exporter as there are use cases in DPDK/SPDK to connect GPU memory into VFIO/iommufd and it is hard to abuse the API as an exporter.
The physical address list exporter returns a physical address list in a simple kvalloc'd array of struct phys_vec.
As far as I can see that is still a pretty big NO-GO.
We have seen so many problems with direct physical address access by the importer that I clear don't want to repeat that performance.
You've said, this is why I used the EXPORT_SYMBOL_FOR_MODULES() - iommufd does not have any problems to use this correctly.
Why is that not good enough? As I understand it your objection isn't that there is a technical issue with iommufd's implementation it is that some other driver could import phys, do it wrong and make a mess. I think EXPORT_SYMBOL_FOR_MODULES() fully addresses this, no?
The only past problems you've raised were related to improperly using VMAs, that isn't happening here.
My main question is why does IOMMUFD need the physical address in the first place?
CPU iommu hw only works in physical address.
If that is really strictly necessary then I strongly suggest to not touch drivers/dma-buf in any way, but only do this is private interface between iommufd and KVM.
This isn't between iommufd and kvm. If it was just that we'd probably be able to keep going with the private path like VFIO/iommufd already has.
The two paths we are interested in:
1) VFIO to KVM Allow KVM to import a FD instead of using a VMA like iommufd now can. 2) GPU and RDMA drivers to IOMMUFD Support SPDK and DPDK type userspace drivers to work with GPU memory This is becoming a popular topic
Jason