On 9/30/26 10:18, Leon Romanovsky wrote: > 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`.
No, exactly that is a no-go. The neither the framework nor the importer should see the p2pdma_provider. Only fully translated addresses where the DMA access should happen. > > 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? What you can do is to forward declare enum pci_p2pdma_map_type and than pass that 1 to 1 from the exporter to the importer. Regards, Christian. > > 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. >>>> >>>> >>
