linux-kernel - Re: [PATCH 2/2] arm64: dts: qcom: agatti: Address Gunyah memory alignment needs

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: <ba3f479d-1233-4e6a-8593-5c7fe5e79762@oss.qualcomm.com>
Date: Thu, 8 Jan 2026 13:43:30 +0100
From: Konrad Dybcio <konrad.dybcio@....qualcomm.com>
To: Sumit Garg <sumit.garg@...nel.org>
Cc: Bjorn Andersson <andersson@...nel.org>, linux-arm-msm@...r.kernel.org,
        devicetree@...r.kernel.org, konradybcio@...nel.org, robh@...nel.org,
        krzk+dt@...nel.org, conor+dt@...nel.org, akhilpo@....qualcomm.com,
        vikash.garodia@....qualcomm.com, dikshita.agarwal@....qualcomm.com,
        robin.clark@....qualcomm.com, lumag@...nel.org,
        linux-kernel@...r.kernel.org, Sumit Garg <sumit.garg@....qualcomm.com>
Subject: Re: [PATCH 2/2] arm64: dts: qcom: agatti: Address Gunyah memory
 alignment needs

On 1/8/26 11:50 AM, Sumit Garg wrote:
> On Wed, Jan 07, 2026 at 12:29:02PM +0100, Konrad Dybcio wrote:
>> On 1/5/26 6:46 AM, Sumit Garg wrote:
>>> On Sat, Jan 03, 2026 at 09:49:04AM -0600, Bjorn Andersson wrote:
>>>> On Mon, Dec 29, 2025 at 12:42:58PM +0530, Sumit Garg wrote:
>>>>> From: Sumit Garg <sumit.garg@....qualcomm.com>
>>>>>
>>>>> Gunyah hypervisor requires it's memory start address to be 2MB aligned.
>>>>> So the address map for Agatti is updated to incorporate that requirement.
>>>>> This should be a backwards compatible DT change which should work with
>>>>> legacy QHEE based firmware stack too.
>>>>>
>>>>
>>>> How come this isn't conveyed to the operating system using the UEFI
>>>> memory map?
>>>>
>>>
>>> I agree that with EFI boot, the information is getting conveyed via EFI
>>> memory map. But there will be non-EFI boot scenarios as well in case of
>>> U-Boot. And moreover I suppose we need to keep the reserved memory
>>> ranges in DT updated to reflect the actual memory map.
>>
>> Can U-Boot not do the same by altering /reserved-memory or /memory/reg?
> 
> I suppose you are referring to DT fixups here, we generally try to keep
> them to a minimum required in U-Boot.
> 
> BTW, don't we want to keep reserved memory ranges updated in DT? Or we plan
> to drop them altogether?

Generally I believe they're only a necessary evil..

Since Gunyah-on-Agatti doesn't seem to have been released yet, it would
seem like a sane idea to fix the issue in the firmware. If it was, well..

On UEFI-enabled targets, we can largely rely on the reservations coming
from there, only adding some carveouts for e.g. PIL regions and SMEM (not
because they're not resereved, but because we need a pointer to them)

Konrad