On Wed, Sep 30, 2026 at 09:00:57AM +0200, Christian König wrote: > On 9/29/26 19:57, Leon Romanovsky wrote: > > On Tue, Sep 29, 2026 at 03:39:42PM +0200, Christian König wrote: > >> On 9/29/26 15:23, Leon Romanovsky wrote: > >>> On Tue, Sep 29, 2026 at 11:34:05AM +0200, Christian König wrote: > >>>> On 9/28/26 13:19, Leon Romanovsky wrote: > >> ...>> > >>>>> + return pci_p2pdma_map_type_tlp(provider, attach->dev, > >>>>> tlp_flags); > >>>> > >>>> This function call here *must* be in the exporter and not the DMA-buf > >>>> framework. > >>>> > >>>> So clear NAK to putting that here. > >>> > >>> "Look, it is easy to complain you don't like how it looks, but this > >>> stuff is hard there are lots of competing concerns, if you have a > >>> better idea now is a good time to present it." > >>> https://lore.kernel.org/all/[email protected]/#t > >>> > >>> Do you have a viable solution? > >> > >> Ok, that sounds like you haven't understood why I'm rejecting this. > >> > >> By moving the calls to pci_p2pdma functions into DMA-buf you bypass the > >> NAK to expose those functions to drivers from the DMA maintainers. > > > > No, you have misunderstood Hellwig's position. His request was to ensure > > that only > > subsystems deal with P2P internals. He was perfectly fine with bringing P2P > > complexity into dma-buf, since it is the agreed-upon mechanism for sharing > > DMA > > regions between devices. > > Thanks for clearing that up, I indeed didn't realized that. > > But that is pretty much against my standpoint that I don't want any P2P > complexity in DMA-buf. > > > > > So this is not a NAK bypass; it is a correct implementation of his request. > > He handled P2P-related complexity in the block layer. > > > > Let's add Christoph to the thread so he can correct me if I'm wrong. > > > >> > >> I unfortunately didn't understood that when the dma-buf-mapping.c code was > >> added and just assumed that you just needed a place to put some common > >> code. > > > > That is not correct. Devices A and B share a DMA region via the dma-buf > > mechanism. Where do you expect the code common to dma-buf to be placed? > > In the DMA layer! > > >> > >> So as long as that NAK from the DMA maintainers to expose the pci_p2p > >> functions to drivers stand I will push hard to get that stuff removed > >> again from DMA-buf as well. > > > > Are you seriously suggesting that every dma-buf driver in the world should > > have to reimplement this mess? > > Well I completely agree that this should probably not be replicated into each > exporter, but that is the job of the DMA layer and not DMA-buf. > > The purpose of DMA-buf is to exchange DMA addresses between an exporter and > one or more importers and handle things like lifetime and synchronization of > accesses. > > What the framework should do is to transport the capabilities of the importer > to the exporter, e.g. what physical connections we have etc.. > > What the framework can also do is to have additional information from the > exporter to the importer regarding addresses and mappings, for example if > they are bus, IOVA or some special internal DMA addresses or how to stitch > together your PCIe TLP or whatever.
At a minimum, exporters need to pass `p2pdma_provider`. If I keep the “dma-buf: Let exporters hand out the P2PDMA provider behind a buffer” patch, I can move the P2P TLP types back into `p2pdma.c` and export only the function that indicates whether ATS is required. Is it ok? Thanks > > As long as both the exporter and importer agree on what those values mean I > have no problem at all with that. > > But how those DMA addresses come to be should *absolutely not* be part of > DMA-buf! The complexity of that is seriously not something we should have > here. > > Regards, > Christian. > > > > > Thanks > > > >> > >> What you try to do here is seriously not ok and I will push back hard on > >> that in the future. > >> > >> Regards, > >> Christian. > >> > >>> > >>> Thanks > >>> > >>>> > >>>> Regards, > >>>> Christian. > >> > >> >
