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/[email protected]/
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
