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

Christian König
2026-04-22T12:39:36Z

On 4/22/26 13:53, Jason Gunthorpe wrote:
> 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.

Mhm, that sounds like what I wanted to say wasn't understood.

> Can you be more specific please, I still have no idea what you are
> thinking in terms of an acceptable implementation.

Let me try to describe it differently:

The iommufd deals with iommu_domain structures which userspace can map different things into.

So of hand I would say that an interface to map DMA-buf into such an iommu_domain should look something like this:

dma_buf_map_attachment_iommu(struct dma_buf_attachment *attachment, struct iommu_domain *domain, unsigned long iova, unsigned long offset, size_t size, ...);

The DMA buf exporter then maps the its data into the iommu_domain at iova starting with offset from within the buffer and size number of bytes.

Regards,
Christian.

>
> Jason