Re: [PATCH v7 1/9] arm64: dts: lx2160a-rev2: extend 32-bit, and add 64-bit pci regions

["Arnd Bergmann" <arnd@arndb.de>]

On Sun, May 24, 2026, at 19:12, Josua Mayer wrote:
> Am 24.05.26 um 17:13 schrieb sashiko-bot@kernel.org:

>>> -	ranges = <0x81000000 0x0 0x00000000 0x80 0x00010000 0x0 0x00010000
>>> -		  0x82000000 0x0 0x40000000 0x80 0x40000000 0x0 0x40000000>;
>>> +	ranges = <0x81000000 0x00 0x00000000 0x80 0x00010000 0x00 0x00010000>, /* 16-Bit IO Window */
>>> +		 <0x82000000 0x00 0x40000000 0x80 0x40000000 0x00 0xc0000000>, /* 32-Bit - non-prefetchable */
>>> +		 <0xC3000000 0x84 0x00000000 0x84 0x00000000 0x04 0x00000000>; /* 64-Bit - prefetchable - 16GB */
>> [Severity: High]
>> Does expanding the 32-bit PCI outbound window to 3GB (0xc0000000) cause it to
>> overlap with inbound system memory?
>>
>> System memory starts at physical address 0x80000000. Since there isn't a
>> dma-ranges property mapping inbound DMA to a different bus address, system
>> memory uses a 1:1 mapping, meaning inbound DMA targets 0x80000000 and above.
>>
>> If a PCIe device requests a large 32-bit BAR, the kernel might allocate it
>> within this 0x40000000-0xffffffff range. This causes the Root Port's
>> downstream bridge Memory Limit register to be programmed to a value >=
>> 0x80000000.
>>
>> A Root Port won't forward upstream memory transactions if the address falls
>> within its programmed downstream window, as it assumes it is peer-to-peer
>> traffic.
>>
>> Could this intercept endpoint DMA targeting system memory in the overlapped
>> range and cause system hangs?
> This configuration was tested with NVMe and GPUs,
> the SMMU should ensure isolation pci bus addresses do not overlap with
> physical ram base address.

I noticed the same thing while reading through the pull request
for 7.2, and I think the bot message is correct here. The SMMU
does not help here because addresses on the same bus are routed
inside of the PCIe host bridge rather than directed to the host
side. If the non-prefetchable ranges ever get assigned to an
address 0x80000000, this definitely breaks.

You will not hit this in most tests, because large MMIO windows
are likely to be 64-bit capable and will end up in the
prefetchable range and addresses are usually assigned from
the lowest address. You can try to force the bug by starting the
non-prefetchable window just below the start of RAM for testing,
which will assign some of the devices to the RAM area.

        Arnd