On 4/13/26 14:16, Jason Gunthorpe wrote:
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?
No, not even remotely. I clearly don't want such an interface in DMA-buf at all.
You can do that as private iommufd interface, e.g. where iommufd offers the functionality to say give me PFNs if you want that.
But when there is a DMA-buf interface even if it is limited to iommufd then others will want that as well and that is not something we should do again.
Even for iommufd I think we don't need that. What iommufd does is basically manipulating a specific IOMMU address space. So the interface should be to give that address space to DMA-buf and say hey please map you backing store at this address into this address space.
Regards, Christian.
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:
- VFIO to KVM Allow KVM to import a FD instead of using a VMA like iommufd now can.
- 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