Re: [PATCH v4 06/18] PCI/P2PDMA: Gate the host bridge whitelist warning on verbose

[Logan Gunthorpe]

On 2026-08-21 13:38, Leon Romanovsky wrote:
> From: Leon Romanovsky <leonro@xxxxxxxxxx>
> 
> calc_map_type_and_dist() prints every other diagnostic under its verbose
> argument, but reaches the "Host bridge not in P2PDMA whitelist" warning
> through host_bridge_whitelist(), which it hands acs_redirects instead.
> A caller that asked for a silent answer still gets the warning whenever
> any port on the path has an ACS redirect bit set, the CPU is not
> whitelisted by cpu_supports_p2pdma(), and the host bridge is not in
> pci_p2pdma_whitelist[].
> 
> pci_p2pmem_find_many() is such a caller. It sweeps every device with
> published p2pmem and asks for the distance to each client with
> verbose=false, and pci_p2pdma_distance_many() recomputes rather than
> consulting the map_types cache, so the warning repeats on every sweep.
> 
> The argument was never meant to say "ACS redirects were found". When
> commit cf201bfe8cdc ("PCI/P2PDMA: Warn if host bridge not in whitelist")
> added it, acs_redirects was a bool pointer that the quiet entry point
> passed as NULL:
> 
> 	if (verbose)
> 		map = calc_map_type_and_dist_warn(provider, pci_client,
> 						  &distance);
> 	else
> 		map = calc_map_type_and_dist(provider, pci_client,
> 					     &distance, NULL, NULL);
> 
> so the argument was true on exactly the path that commit describes.
> Folding the two entry points into one verbose flag turned the pointer
> into a value and left the call site alone, silently narrowing the
> warning to paths that carry an ACS redirect.
> 
> Pass verbose. This also restores the warning for a verbose caller that
> takes the host bridge route with no ACS redirect on the path, which
> until now was told it could not use peer-to-peer DMA without being told
> which vendor and device would have to be added to the whitelist.
> 
> Tested-by: Tushar Dave <tdave@xxxxxxxxxx>
> Fixes: d1b8dc09dd71 ("PCI/P2PDMA: Simplify distance calculation")
> Signed-off-by: Leon Romanovsky <leonro@xxxxxxxxxx>

Took me a bit of effort to understand this history, but I think the end
result makes more sense than what is currently there.

Reviewed-by: Logan Gunthorpe <logang@xxxxxxxxxxxx>