On Mon, 2026-09-21 at 10:10 -0300, Jason Gunthorpe wrote:

On Mon, Sep 21, 2026 at 08:40:41AM +0200, Thomas Hellström wrote:

...

On Fri, 2026-09-18 at 14:05 -0300, Jason Gunthorpe wrote:

...

On Fri, Sep 18, 2026 at 03:42:28PM +0200, Thomas Hellström wrote:

...

1. Xe attachment check if pci_p2pdma_distance() returns OK for

the path. Then Xe always sets up dma-addresses using dma_map_resource().

Open coding pci_p2pdma_distance() in drivers is a hack. Using dma_map_resource() like this was never "allowed".

We've fixed things so these hacks are not needed, the drivers need to move over to things like dma_buf_phys_vec_to_sgt() and the hmm helpers to use the DMA API correctly.

...

1a) Let's say the importer (Xe) has ATS enabled, and the exporter is supposed to map dma_addresses. In between there is a switch that allows direct traffic. Now with your patch series, How would the exporter know that Xe has ATS enabled and therefore should return IOVA mappings rather than the BUS addresses representing the shortcut.

The thing that does the DMA map must be aware of what PCI TLPs the PCIe initiator will use to compute the proper P2P mapping mode.

ATS always needs an IOVA but that still doesn't mean the P2P will work.

...

It seems to me that a pci-device settable flag "ATS always enabled" should be enough to fix both issues?

It should be be per-mapping to support the NIC workflow that isn't a global operation.

OK. It looked to me from the series like the NIC workflow was to adapt its ATS settings per mapping depending on the p2p mapping type returned rather than vice versa. If so it would just clear "ATS always enabled".

Admittedly a per-mapping flag would be more flexible, but also would require changed internal APIs?

Ah you didn't send this to the list, was it intentional?

No, Just hit the wrong reply-button. +lists again.

mlx5 has both cases, some DMA is flexable and can do either, some is non-ATS only.

OK.

Jason

Thanks, Thomas