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

[Leon Romanovsky <leonro@nvidia.com>]

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/


> 
> What do you think?
> 
> Jason