Re: [RFC v2 0/8] dma-buf: Add support for mapping dmabufs via interconnects

[Jason Gunthorpe <jgg@nvidia.com>]

On Sun, Oct 26, 2025 at 09:44:12PM -0700, Vivek Kasireddy wrote:
> In a typical dma-buf use case, a dmabuf exporter makes its buffer
> buffer available to an importer by mapping it using DMA APIs
> such as dma_map_sgtable() or dma_map_resource(). However, this
> is not desirable in some cases where the exporter and importer
> are directly connected via a physical or virtual link (or
> interconnect) and the importer can access the buffer without
> having it DMA mapped.

I think my explanation was not so clear, I spent a few hours and typed
in what I was thinking about here:

https://github.com/jgunthorpe/linux/commits/dmabuf_map_type

I didn't type in the last patch for iommufd side, hopefully it is
clear enough. Adding iov should follow the pattern of the "physical
address list" patch.

I think the use of EXPORT_SYMBOL_FOR_MODULES() to lock down the
physical addres list mapping type to iommufd is clever and I'm hoping
addresses Chrsitian's concerns about abuse.

Single GPU drivers can easilly declare their own mapping type for
their own private interconnect without needing to change the core
code.

This seems to be fairly straightforward and reasonably type safe..

What do you think?

Jason