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-zFAKSiMehGzQg3Teyw7eLdGz4_sCopj2_pGnKNO96z71uQ@mail.gmail.com>
Date: Fri, 28 Nov 2025 22:39:57 +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,

On Fri, 28 Nov 2025 at 22:10, Christopher Obbard
<christopher.obbard@...aro.org> wrote:
>
> 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 ?

Small update, I create an issue to track this bug:
https://gitlab.com/Linaro/arm64-laptops/linux/-/issues/23
and opened a merge request with Stephan's patch:
https://gitlab.com/Linaro/arm64-laptops/linux/-/merge_requests/1


Cheers!

Chris

>
> 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
> > >
> >