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/[email protected]/ > > What do you think? > > Jason
