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 04:04:19PM +0200, Christian König wrote:
> > Well, my first reaction is very negative, this suggestion is leaking
> > deep internal details like iommu_domain out of the single place that
> > needs them - iommufd - into about 6 exporter drivers. Not nice. I have
> > the mirror of your concern that I don't trust DRM drivers not to abuse
> > the iommu_domain pointer in some very creative way.
> 
> Yeah, of course that argument goes into both directions.
> 
> The point is just that we have much more importers than exporters to
> handle, and from experience it was always the importer who messed
> things up.

I think that is true for scatter list, but it is the opposite for this
iommufd connection. One iommufd, many exporting drivers.

I imagine all the compute/server type DRM drivers plus RDMA and VFIO
will want to implement exporters. That's at least 5..

> Background is that the importer integrates the buffer into it's own
> handling which might not be made for the way the exporter is
> expecting things to be used.

I think dmabuf has robust rules for lifecycle, and the invalidation
notification mechanism. It is complex and perhaps not well understood,
but all the technical pieces are there to allow a correct importer.

I fully agree if the importer messes up the rules things will be
broken and you will have corruption issues. But they can mess up
scatterlist liftime too! Yes, VMAs are a really easy way to mess it
up, and for some reason DRM drivers really want to put things in
VMAs <shrug>
 
> > However. With a suitable helper we can largely isolate this to a
> > single function and yeah I can see making this functional.
> 
> The important point is that the exporter should not need to expose
> it's physical data store and how it's housekeeping works.

I'd argue the other side just as strongly, the importer should not
have to expose its underlying HW objects or how they work either.

Would you be open to an in-between? The exporter and importer both
have information that should not leak into each other's drivers. 

What if the dmabuf mapping type core code was the only thing that had
access to *BOTH*? The exporter provides the address data, the importer
provides the iommu_domain. The core code, and only the core code, has
both and does the required operation?

I think that satisfies your goal to prevent importers from accessing
the information?

In the language of this series I imagine a PAL exporter, and an
iommu_domain importer. No PAL *importer*, no exposing phys_addr_t to
importers.

Instead the core code will match a PAL exporter to an iommu_domain
importer. The core code will provide a "converter function" from PAL
to iommu_domain. Only this converter function can see the phys_addr_t
and iommu_domain together. The exporter does not see iommu_domain.

This is appealing to reduce the driver burden. A converter that calls
dma_buf_phys_vec_to_sgt() could exist. Then a driver only has to
implement PAL exporter and it works with two of the importer mapping
types. Makes it easier to introduce future types (eg scatterlist-ng)

I don't think it would be a nice outcome if every exporting driver has
to open code several dma_buf_phys_vec_to_XXX() helper calls.

(I say PAL exporter here from my non-DRM perspective, but maybe DRM
wants a bo/ttm/gem/page[] or something as the exporter mapping type)

> > Do you have a positive feeling about the general mapping type system
> > from the earlier patches?
> 
> As far as I can see that goes into the right direction, yes.

Okay, do you have guidance what you'd like to see as a non-RFC
posting? Ideally I'd like to make smaller steps, this RFC was
responding to your request to see everything.

a) just the core dmabuf infrastructure for mapping type infra and SGL
b) a plus some set of the simpler/safer driver conversions
c) a plus all the driver conversions

?

If we agree to the "converter functions" idea I imagine the following
sequence of series:

1) Introduce basic dma buf mapping types for SGL
   side activity: Move drivers from legacy to SGL mapping type

2) Introduce dma buf mapping type conversion functions. With PAL to
   SGL converter. Restructure vfio to be PAL only and rely on the
   converter for SGL
   side activity: Move more exporters to PAL/etc away from SGL

3) Introduce dma buf iommu_domain importer only mapping type. Core
   code converter from PAL to iommu_domain. iommufd implementation of
   the importer

Thanks,
Jason