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: <CACr-zFBLC+dhM1Unv6iWaqg2H8DC2UbHQ_aQ9-am++MPUgg8ow@mail.gmail.com>
Date: Fri, 28 Nov 2025 22:10:14 +0000
From: Christopher Obbard <christopher.obbard@...aro.org>
To: Jonathan Marek <jonathan@...ek.ca>
Cc: Stephan Gerhold <stephan.gerhold@...aro.org>, 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)

Hi,

Sorry to hijack this thread, but I've been carrying this patch to
workaround the buggy firmware from Stephan for my Lenovo T14s with
64gb RAM which seems to make Linux boot & work just fine with
systemd-boot.
Of course, it's a hack and not ready for upstream.

On another topic, perhaps we need to add this to
https://gitlab.com/Linaro/arm64-laptops/linux , what do you think
Stephan ?

Chris


commit 16e21600c6a65ace0c75b5a722e27ced8e1bfc48
Author: Stephan Gerhold <stephan.gerhold@...aro.org>
Date:   Thu Mar 6 17:41:15 2025 +0000

    HACK: efi-stub: Exclude 40-bit memory

diff --git a/drivers/firmware/efi/libstub/efi-stub.c
b/drivers/firmware/efi/libstub/efi-stub.c
index 874f63b4a383..355a9b2c0818 100644
--- a/drivers/firmware/efi/libstub/efi-stub.c
+++ b/drivers/firmware/efi/libstub/efi-stub.c
@@ -106,6 +106,17 @@ efi_status_t
efi_handle_cmdline(efi_loaded_image_t *image, char **cmdline_ptr)
 {
        char *cmdline __free(efi_pool) = NULL;
        efi_status_t status;
+       efi_physical_addr_t addr;
+       unsigned long pages;
+
+       addr = 0x0000008800000000;
+       pages = 0x800000000 / EFI_PAGE_SIZE;
+       status = efi_bs_call(allocate_pages, EFI_ALLOCATE_ADDRESS,
+                                                EFI_RESERVED_TYPE,
pages, &addr);
+       if (status != EFI_SUCCESS) {
+               efi_err("failed to reserve upper 32 GiB (40-bit memory)\n");
+               return EFI_OUT_OF_RESOURCES;
+       }

        /*
         * Get the command line from EFI, using the LOADED_IMAGE




Cheers!

Chris


On Fri, 28 Nov 2025 at 16:36, Jonathan Marek <jonathan@...ek.ca> wrote:
>
> 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
> >
>