Re: [PATCH RFC 21/26] dma-buf: Add the Physical Address List DMA mapping type

[Jason Gunthorpe <jgg@nvidia.com>]

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