linux-kernel - Re: [PATCH 1/3 v2] dt-bindings: PCI: s32g: Add NXP PCIe controller

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <nzznoiri4n7krpid4lp4pax2dge6vwdj3eqyxqob4bzf6gmlzy@a6moyj74ehzp>
Date: Fri, 17 Oct 2025 20:42:24 +0530
From: Manivannan Sadhasivam <mani@...nel.org>
To: Arnd Bergmann <arnd@...db.de>
Cc: Lorenzo Pieralisi <lpieralisi@...nel.org>, 
	Vincent Guittot <vincent.guittot@...aro.org>, Chester Lin <chester62515@...il.com>, 
	Matthias Brugger <mbrugger@...e.com>, Ghennadi Procopciuc <ghennadi.procopciuc@....nxp.com>, 
	NXP S32 Linux Team <s32@....com>, bhelgaas@...gle.com, jingoohan1@...il.com, 
	Krzysztof Wilczyński <kwilczynski@...nel.org>, Rob Herring <robh@...nel.org>, krzk+dt@...nel.org, 
	Conor Dooley <conor+dt@...nel.org>, Ionut.Vicovan@....com, Larisa Grigore <larisa.grigore@....com>, 
	Ghennadi Procopciuc <Ghennadi.Procopciuc@....com>, ciprianmarian.costea@....com, 
	Bogdan Hamciuc <bogdan.hamciuc@....com>, Frank Li <Frank.li@....com>, 
	linux-arm-kernel@...ts.infradead.org, linux-pci@...r.kernel.org, devicetree@...r.kernel.org, 
	linux-kernel@...r.kernel.org, imx@...ts.linux.dev, Niklas Cassel <cassel@...nel.org>
Subject: Re: [PATCH 1/3 v2] dt-bindings: PCI: s32g: Add NXP PCIe controller

On Thu, Oct 09, 2025 at 11:16:02PM +0200, Arnd Bergmann wrote:
> On Thu, Oct 9, 2025, at 20:47, Manivannan Sadhasivam wrote:
> > On Wed, Oct 08, 2025 at 07:56:44PM +0200, Arnd Bergmann wrote:
> >> On Wed, Oct 8, 2025, at 17:19, Manivannan Sadhasivam wrote:
> >>
> >> That is not my impression from reading the code: At least for
> >> the case where both devices are on the same bridge and they
> >> use map_type=PCI_P2PDMA_MAP_BUS_ADDR, I would expect the DMA
> >> to use the plain PCI bus address, not going through the
> >> dma-ranges+ranges translation that would apply when they are
> >> on different host bridges.
> >> 
> >
> > Right, but I don't get the overlap issue still. If the P2P client triggers a
> > write to a P2P PCI address (let's assume 0x8000_0000), and if that address
> > belongs to a an endpoint in a different domain, the host bridge should still
> > forward it to the endpoint without triggering write to the RAM.
> 
> If 0x8000_0000 is an endpoint in a different domain, I would expect the
> DMA transfer to go to the RAM at that address since the DMA has to leave
> the PCI host bridge upstream by following its inbound windows.
> 
> This is not the problem I'm talking about though, since cross-domain
> P2P is not particularly well-defined.
> 
> > Atleast, I don't see any concern from the outbound memory translation point of
> > view.
> >
> > Please let me know if there is any gap in my understanding.
> 
> To clarify: I don't think that programming the output translation this
> way is the problem here, but assigning memory resources to ambiguous
> addresses is. The host bridge probe uses the 'ranges' both for
> setting up the outbound window and the bus resources. 
> 
> If the PCI bus scan assigns address 0x8000_0000 to the memory BAR
> of a device, and that device or any other one in the /same/
> domain tries to DMA to DRAM at address 0x8000_0000, it would likely
> reach the memory BAR instead of DRAM. If for some reason it does reach
> DRAM after all, it would be unable to do a P2P DMA into the BAR when
> it tries.
> 

I tried to verify how the Root Port is supposed to behave in this scenario, but
I couldn't conclude on anything. So it looks like this overlapping *might*
create issues with P2PDMA and DRAM access. Thanks for spotting and also for
persisting with my lack of understanding :)

> If the PCI scan already checks for overlap between the DT "ranges"
> and other resources (DRAM or MMIO) before assigning a BAR, this may
> be a non-issue, but I haven't found the code that does this.
> Looking at pci_bus_allocate_dev_resources() it seems that it would
> attempt to assign an overlapping address to a BAR but then fail
> to claim it because of the resource conflict. If that is the
> case, it would not actually have an ambiguous DMA routing
> but instead the device would fail to be probed because of the
> conflict.
> 

AFAICS, the existing resource checks only finds out the overlap between the
resources assigned to the devices, not between the DRAM or MMIO. This is
something we should do in devm_of_pci_get_host_bridge_resources() IMO.

- Mani

-- 
மணிவண்ணன் சதாசிவம்