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