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

[Jason Gunthorpe <jgg@nvidia.com>]

On Wed, Oct 29, 2025 at 11:25:34AM +0200, Leon Romanovsky wrote:
> On Tue, Oct 28, 2025 at 09:27:26PM -0300, Jason Gunthorpe wrote:
> > 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..
> 
> It makes me wonder what am I supposed to do with my series now [1]?
> How do you see submission plan now?
> 
> [1] https://lore.kernel.org/all/cover.1760368250.git.leon@kernel.org/

IMHO that series needs the small tweaks and should go this merge
window, ideally along with the iommufd half.

I think this thread is a topic for the next cycle, I expect it will
take some time to converge on the dmabuf core changes, and adapting
your series is quite simple.

Jason