On Wed, Apr 22, 2026 at 10:17:06AM +0200, Christian König wrote:
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.
I'm not sure what a "private" interface means if VFIO and DRM/RDMA drivers need to implement the exporter side? That's not exactly private if it in so many drivers.
I've tried to make the importer side private, if you have better ideas how to make it more private please share them.
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.
You can say no, that's the point of the export symbol restriciton.
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.
Isn't that pretty much exactly what this series is? Aren't you splitting hairs to say an "address space" requesting physical is OK but a "mapping type" requesting physical is not? The net result is exactly the same, physical addresess flow from exporter to importer.
To be clear, there is no way, nor should there be a way, to use the DMA API to create a reliable dma_addr_t that is 1:1 with phys_addr_t.
Can you be more specific please, I still have no idea what you are thinking in terms of an acceptable implementation.
Jason