Re: PCI_P2PDMA_MAP_BUS_ADDR and PCIe ATS?

[Jason Gunthorpe <jgg@nvidia.com>]

On Wed, Aug 19, 2026 at 08:42:10AM +0200, Thomas Hellström wrote:

> > Probably what you want to do is add a flag that the device is going
> > to
> > use ATS for the P2P DMA. Then we can force setup an IOVA and check
> > the
> > fabric path for translated request routing to make sure it will work.
> 
> Yes, sounds like a way forward. To be honest, we don't have an existing
> use-case yet, but taking the union of how we want to configure our GPUs
> moving forward and the support requests we see from p2pdma users, this
> is probably something we are going to hit sooner than later.

I will say we've had to deploy alot of experts to design our systems
and it is really hard to get something that actually works :|

> > And yes, there is an existing issue with DMABUF not being able to
> > negotiate these little pathing details with the importer when the
> > exporter forms the scatterlist..
> 
> Yes, it was when looking into that I actually stumbled upon the ATS
> issue as well. I recall you and Christian have touched upon this in the
> past. What is an acceptable way forward here? A dma_map_resource_p2p()
> interface that takes into account the mapping type?

IDK, it is painful. There is alot of stuff coming that the importer
will need to customize when performing the mapping. Locking the DMA
mapping process in the exporter is not helpful.  For example your
device might need to say 'I will always use ATS', while mlx5 would
prefer 'Should I disable ATS for this mapping'.

Christian seems unrelenting on this point so I don't really have a
good solution beyond some endless list of single user flags.

I wanted to rebase and revise the mapping type series but I've been
just buried in security things, patch reviews and travel lately. Maybe
I will get there after this merge window

Jason