Re: [PATCH v13 00/19] PCI/P2PDMA: Route peer-to-peer DMA by TLP class

[Bjorn Helgaas <helgaas@kernel.org>]

On Wed, Nov 11, 2026 at 02:16:02PM +0200, Leon Romanovsky wrote:
> On Thu, Nov 05, 2026 at 12:04:31PM +0200, Leon Romanovsky wrote:
> > Punch line for Linus from Jason:
> > "Enhance detecting if the PCI fabric can support a peer to peer path
> > by evaluating the full bi-directional fabric path over each of the
> > three traffic type ACS controls. Expand the number of fabric
> > configurations where the P2P algorithm makes the correct determination
> > of support to include non-uniform ACS and situations where translated
> > takes different routes from untranslated."
> 
> Bjorn,
> 
> Just a friendly reminder.

Thanks for the reminder.  I put this on pci/p2pdma for build testing
(no issues expected; I always try to get build testing before merging
into linux-next).

I'm still struggling to describe this in a way that connects to the
code changes and is accessible to non-experts, so please correct
things I get wrong here.

I had the impression that this series helps VMs by making P2PDMA work
with passthrough devices in cases where it currently doesn't, but
maybe that's not the case; I don't see any mention of that in the
series.

IIUC the P2PDMA core doesn't actually *control* any TLP routing, i.e.,
it doesn't change any ACS controls or change any TLP attributes that
affect how TLPs are routed, so to me, these subject lines suggest more
than is actually happening:

  Route Relaxed Ordering Completions directly
  Reject Translated Requests blocked by Translation Blocking
  Route Translated Requests under Direct Translated P2P

It seems like we're just *learning* whether RO Completions will be
routed directly, whether Translated Requests will be rejected, etc?

I think the core basically looks at the ACS controls on the path
between two devices and decides whether:

  (a) the devices can do P2P DMA directly (PCI_P2PDMA_MAP_BUS_ADDR),

  (b) they can do P2P DMA but only through host bridges on the
  allowlist (PCI_P2PDMA_MAP_THRU_HOST_BRIDGE),

  (c) no P2P DMA is possible (PCI_P2PDMA_MAP_NOT_SUPPORTED),

  (d) PCI_P2PDMA_MAP_NONE -- I don't understand this one; the comment
  says "not a P2PDMA transfer", and pci_p2pdma_state() returns it when
  the page is not a p2pdma_page, I guess because
  pci_p2pdma_add_resource() has not set MEMORY_DEVICE_PCI_P2PDMA?
  Not sure how this is used.

I guess one benefit of this series is that a path where P2P Completion
Redirect is set used to mean that pci_p2pdma_map_type() would return
PCI_P2PDMA_MAP_NOT_SUPPORTED (unless the RC was allow-listed), and now
it might return PCI_P2PDMA_MAP_BUS_ADDR because if P2P Request
Redirect is clear, Requests can be routed directly?

That sounds great as long as the Request uses Relaxed Ordering, so the
Completion won't be affected by P2P Completion Redirect.  But devices
aren't *required* to use RO even if enabled, and I'm doubtful that a
non-RO Completion redirected to the RC is going to work.  So I don't
understand how p2pdma.c can guarantee safety.

Translated Requests seems similar -- are we assuming that if ACS
Direct Translated P2P is set and ATS Enable is set, the device
*always* generates Translated Requests?

Bjorn