linux-kernel - Re: [PATCH] arm64: dts: qcom: x1e: bus is 40-bits (fix 64GB models)

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <1aa75dd2-6fb4-e9ca-ca27-c0bd910246fe@marek.ca>
Date: Fri, 28 Nov 2025 11:34:40 -0500
From: Jonathan Marek <jonathan@...ek.ca>
To: Stephan Gerhold <stephan.gerhold@...aro.org>
Cc: linux-arm-msm@...r.kernel.org, Bjorn Andersson <andersson@...nel.org>,
 Konrad Dybcio <konradybcio@...nel.org>, Rob Herring <robh@...nel.org>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
 <conor+dt@...nel.org>, Sibi Sankar <sibi.sankar@....qualcomm.com>,
 Abel Vesa <abel.vesa@...aro.org>, Rajendra Nayak <quic_rjendra@...cinc.com>,
 "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
 <devicetree@...r.kernel.org>, open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] arm64: dts: qcom: x1e: bus is 40-bits (fix 64GB models)

On 11/28/25 11:03 AM, Stephan Gerhold wrote:
> On Fri, Nov 28, 2025 at 09:39:52AM -0500, Jonathan Marek wrote:
>> On 11/28/25 5:26 AM, Stephan Gerhold wrote:

...

>>
>> I am using EL2.
>>
>> Without this patch, DMA buffers allocated in the upper 36-bit physical range
>> will try to use bounce buffers. The dma range from the dts is compared
>> against the physical address, not the virtual address.
> 
> I don't think this is the case for the dma-iommu layer. I debugged a
> crash caused by USB in EL1 on a 64 GiB device earlier this year and it
> was happily using buffers above the 36-bit physical range without using
> bounce buffers. There is some code inside dma-iommu for using swiotlb,
> but it's used only for "untrusted" PCI devices and some edge cases with
> unaligned/small buffers.
> 
>>
>> The crash I see is display driver crashes/freezes once a buffer is allocated
>> in the upper 36-bit range and it tries to use bounce buffers. This can
>> happens very quickly under load.
>>
> 
> You could be right about the MSM display driver though, since that
> bypasses dma-iommu and manages the IOMMU itself. I stared at the code a
> bit and I'm not immediately seeing where it would end up calling into
> swiotlb, but it might be hidden somewhere in the endless nesting.
> 

Looks like you are right about this, MSM driver ends up going through 
dma_direct_map_phys(), which decides to use bounce buffers. I didn't try 
to see if other drivers end up using bounce buffers, but it would make 
sense that only MSM driver is affected.

>> The same crash would happen for EL1 as well. I wasn't aware of the EL1
>> broken firmware when I sent this patch, but instead of display freezing I
>> guess the behavior would a hard reset now, which is a bit worse but still
>> unusable unles display/gpu driver is disabled.
>>
>> This patch is correct and should be applied regardless of broken-firmware
>> EL1 cases (where 64GB isn't usable anyway), but I guess the Fixes tag
>> can/should be dropped.
>>
> 
> Please clarify the commit message a bit and mention the two separate use
> cases (EL1 and EL2). I'll leave it up to Bjorn/Konrad to decide whether
> to merge it. At the end you are right and using 64 GiB RAM in EL1 is
> kind of a lost cause anyway.
> 
> Thanks,
> Stephan
>