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 for Android: free password hash cracker in your pocket

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

Message-ID: <aSl48gV9laFb-MR1@linaro.org>
Date: Fri, 28 Nov 2025 11:26:58 +0100
From: Stephan Gerhold <stephan.gerhold@...aro.org>
To: Jonathan Marek <jonathan@...ek.ca>
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 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 would expect that applying your change effectively just enlarges the
I/O virtual address space, which will then be 40-bit instead of just
36-bit. For most devices, even 32-bit of virtual address space should be
enough. A larger address space will only be applied for drivers that
explicitly request a larger DMA mask (e.g. the nvme driver).

We can make this change for correctness, but given that it is only about
the IOVA space, there shouldn't be much functional difference.

# EL1 with Gunyah hypervisor

For EL1, the hypervisor firmware used on most retail laptops limits the
usable DMA memory in the SMMUs to the physical 36-bit range. You are
right that laptops with 64 GiB memory are essentially unusable in EL1
without disabling the physical memory outside the 36-bit range, but
applying this patch would make it even worse.

There are two separate cases:

 - For devices behind the SMMUv2, the situation should be the same as
   above. Increased IOVA space, but no effect on physical address range.
   This is what is currently causing crashes with 64 GiB RAM in EL1.

 - Devices behind the SMMUv3 (PCIe) do not have an IOMMU assigned when
   running in EL1. In this case, the 36-bit dma-ranges prevents PCIe
   devices from using memory outside the 36-bit range. They will fall
   back to bounce buffers in that case. Applying your patch will disable
   that, making it even more likely to crash than before.

Given that x1e80100.dtsi / hamoa.dtsi primarily models the EL1 setup
with Gunyah hypervisor, I don't think it makes sense to apply this patch
as-is. It will just make it even more likely to crash than before.
I suggest adding these overrides in x1-el2.dtso, with the expected
limited effect I described above.

Thanks,
Stephan