Hi Jason, > Subject: Re: [RFC v2 0/8] dma-buf: Add support for mapping dmabufs via > interconnects > > 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.. > > What do you think? It mostly looks OK to me but there are a few things that I want to discuss, after briefly looking at the patches in your branch: - I am wondering what is the benefit of the SGT compatibility stuff especially when Christian suggested that he'd like to see SGT usage gone from dma-buf eventually. Also, if matching fails, IMO, indicating that to the importer (allow_ic) and having both exporter/importer fallback to the current legacy mechanism would be simpler than the SGT compatibility stuff.
- Also, I thought PCIe P2P (along with SGT) use-cases are already well handled by the existing map_dma_buf() and other interfaces. So, it might be confusing if the newer interfaces also provide a mechanism to handle P2P although a bit differently. I might be missing something here but shouldn't the existing allow_peer2peer and other related stuff be left alone? - You are also adding custom attach/detach ops for each mapping_type. I think it makes sense to reuse existing attach/detach ops if possible and initiate the matching process from there, at-least initially. - Looks like your design doesn't call for a dma_buf_map_interconnect() or other similar helpers provided by dma-buf core that the importers can use. Is that because the return type would not be known to the core? - And, just to confirm, with your design if I want to add a new interconnect/ mapping_type (not just IOV but in general), all that is needed is to provide custom attach/detach, match ops and one or more ops to map/unmap the address list right? Does this mean that the role of dma-buf core would be limited to just match and the exporters are expected to do most of the heavy lifting and checking for stuff like dynamic importers, resv lock held, etc? Thanks, Vivek > > Jason
