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.
Again: What is exported and from which path is up to the exporter and only determined when you create a DMA-buf mapping!
In most cases you don't even have a single device which is the DMA-buf exporter.
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....
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.
Regards, Christian.
Thanks