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: <45bee524-d960-5b24-83bd-4dfb3e78fb1d@marek.ca>
Date: Fri, 28 Nov 2025 09:49:01 -0500
From: Jonathan Marek <jonathan@...ek.ca>
To: Konrad Dybcio <konrad.dybcio@....qualcomm.com>,
 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 5:52 AM, Konrad Dybcio wrote:
> On 11/28/25 11:26 AM, Stephan Gerhold wrote:
>> On Thu, Nov 27, 2025 at 04:29:42PM -0500, Jonathan Marek wrote:
>>> Unlike the phone SoCs this was copied from, x1e has a 40-bit physical bus.
>>> The upper address space is used to support more than 32GB of memory.
>>>
>>> This fixes issues when DMA buffers are allocated outside the 36-bit range.
>>>
>>> Fixes: af16b00578a7 ("arm64: dts: qcom: Add base X1E80100 dtsi and the QCP dts")
>>> Signed-off-by: Jonathan Marek <jonathan@...ek.ca>
>>> ---
>>>   arch/arm64/boot/dts/qcom/x1e80100.dtsi | 4 ++--
>>>   1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/arch/arm64/boot/dts/qcom/x1e80100.dtsi b/arch/arm64/boot/dts/qcom/x1e80100.dtsi
>>> index cff34d1c74b60..cd34ce5dfd63a 100644
>>> --- a/arch/arm64/boot/dts/qcom/x1e80100.dtsi
>>> +++ b/arch/arm64/boot/dts/qcom/x1e80100.dtsi
>>> @@ -792,8 +792,8 @@ soc: soc@0 {
>>>   
>>>   		#address-cells = <2>;
>>>   		#size-cells = <2>;
>>> -		dma-ranges = <0 0 0 0 0x10 0>;
>>> -		ranges = <0 0 0 0 0x10 0>;
>>> +		dma-ranges = <0 0 0 0 0x100 0>;
>>> +		ranges = <0 0 0 0 0x100 0>;
>>>   
>>
>> Could you clarify which "issues" (crashes?) you are referring to?
>>
>> We need to distinguish two distinct use cases here, which are both
>> (somewhat) supported upstream: Running in EL1 with the Gunyah hypervisor
>> with the regular DTB and in EL2 with the x1-el2.dtbo applied.
>>
>> # EL2 with x1-el2.dtbo
>>
>> For EL2, I think the 40-bit dma-ranges should indeed work correctly, so
>> we could add your proposed change inside x1-el2.dtso. I'm not sure which
>> issues we are fixing with that though (besides correctness of the
>> hardware description). In EL2, all DMA devices should be behind an
>> IOMMU. In this case, the dma-ranges limit the size of the I/O virtual
>> addresses (DMA addresses) that are given to the devices. The IOMMU maps
>> the DMA buffers to arbitrary physical memory addresses (including
>> outside of the 36-bit range, dma-ranges limits only the DMA address).
> 
> I've been carrying something similar in my working tree for quite
> some time too.. The USB4 PCIe controllers have BAR spaces in the >36b
> region, so this will be necessary anyway.
> 
> As for the broken-firmware laptops, there's only so much we can do.
> A fix for this has been *long* released, but it's up to the OEMs to
> pull it in.
> 
> 
> I'm not fully sure, but I think certain subsystems still have the 36b
> address limitation (camera?), so it would be good to know whether that
> needs to be accounted for
> 
> Konrad
> 

Most devices only support 32-bit address space, and use a 32-bit DMA 
mask (which is the default, I think?) to only get 32-bit virtual 
addresses. Camera driver can set a 36-bit DMA mask if it wants to use 
its whole range.

This patch is about the physical addresses, not virtual. Every device 
can access the full range (without this, the iommu dma driver thinks 
buffers with physical addresses outside 36-bit range are not accessible, 
and tries to use bounce buffers)