Re: PCI_P2PDMA_MAP_BUS_ADDR and PCIe ATS?

["Thomas Hellström" <thomas.hellstrom@linux.intel.com>]

On Tue, 2026-08-18 at 16:03 -0300, Jason Gunthorpe wrote:
> On Tue, Aug 18, 2026 at 05:20:51PM +0200, Thomas Hellström wrote:
> 
> > From my understanding, ATS translated requests would use the fast-
> > path
> > as soon as a translation is established in the device, without the
> > BUS
> > address being explicitly programmed. ACS redirect would block that.
> 
> Oh it's super complex. There are seperate ACS bits for translated and
> untranslated requests. You need a PCI expert to design your fabric
> and
> devices to get a working system unfortunately.
> 
> If you use ATS and don't set the ACS to route all translations to
> host
> then your IOVA space is no longer uniform, you have different results
> depending on which fabric route you take. That's a pretty
> unreasonable
> fabric design, and can't work securely with virtualization.
> 
> > So wouldn't it be better to be safe than sorry and return a host
> > bridge
> > map and make something usable and potentially fast out of something
> > currently unusable?
> 
> What we have today works for lots of devices and if you change it
> like
> this then you'll break existing users.

I guess if there are setups with devices with PCIe ATS enabled but only
ever sending untranslated requests, indeed they would see a performance
regression with this approach.

> 
> 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.

> 
> 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?

Thanks,
Thomas


> 
> Jason