Re: PCI_P2PDMA_MAP_BUS_ADDR and PCIe ATS?

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.

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.

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

Jason