On Wed, Sep 30, 2026 at 04:52:20PM +0200, Christian König wrote:
On 9/30/26 16:32, Leon Romanovsky wrote:
On Wed, Sep 30, 2026 at 01:52:39PM +0200, Christian König wrote:
...
The importer needs a way to obtain device information from the exporter so that it can configure itself correctly.
That won't work with DMA-buf then, the exporter is completely opaque to the importer and that is for really good reasons.
Why in the world does the importer needs to know the information from the exporter before the mapping is created?
It is the exporter who decides how data is accessed by the importer and not the other way around.
There are several reasons:
- This is how DMA-BUF MRs are built in RDMA. In mlx5, they rely on the ODP mechanism, which requires an MKEY to be created first. See commit 90da7dc8206a (“RDMA/mlx5: Support dma-buf based userspace memory region”).
I know that patch, but I absolutely don't understand where the problem is.
- P2P routing is a property of devices, not memory. It is known and remains stable.
No, absolutely not. You are making completely incorrect assumptions how DMA-buf works.
Maybe, but I understand how the kernel, PCI, and P2P DMA work, and dma-buf seems to operate in a parallel reality that is not aligned with any of them.
Again: What is exported and from which path is up to the exporter and only determined when you create a DMA-buf mapping!
Let's discuss the PCI P2P case, where `p2pdma_provider` is present. In this flow, the exporter has a PCI device, and the importer also has one when it attaches. The decision about how to construct the addresses is made at that point. Note that both the exporter and importer are PCI P2P devices, so the importer should make the request.
In most cases you don't even have a single device which is the DMA-buf exporter.
How is it possible for exporter with p2pdma_provider?
Only while creating the mapping the underlying access path is finally determined. It can be that P2P is used, it can be that internal connections are used, it can be that the data is moved to system memory....
But we are talking about in-tree exporters: RDMA, VFIO e.t.c
That's why we have the distinction between attaching and importer and the importer creating a mapping.
- See the VFIO TPH ST discussion, where the requirement to obtain the exporter’s P2P information in the importer was raised again.
As far as I can see there isn't any. The TPH/ST information are just passed through from the exporter to the importer.
We could define a bit better what needs to come first the mapping or the TPH/ST query but for their use case that is actually irrelevant.
They need an access to p2pdma_provider too. https://lore.kernel.org/linux-rdma/CAH3zFs2rhg6-b-pVDps1V8LsM4Dn48t4J4LFVyKO...
Thanks
Regards, Christian.
Thanks