[PATCH 1/1] efi_loader: create memory reservations in ACPI case

[Heinrich Schuchardt]

On 11/18/23 18:10, Simon Glass wrote:
> Hi Heinrich,
> 
> On Thu, 16 Nov 2023 at 02:29, Heinrich Schuchardt
> <heinrich.schuchardt at canonical.com> wrote:
>>
>> ACPI tables cannot convey memory reservations for least ARM and RISC-V.
>> x86 uses the BIOS E820 table for this purpose. We cannot simply ignore the
>> device-tree when booting via ACPI.
> 
> Why is that? I had thought that we had to use one or the other. Isn't
> the devicetree irrelevant when booting with ACPI, so we can just drop
> it?

Linux Documentation/arch/arm64/acpi_object_usage.rst, line 718f 
describes the mechanism to convey memory information as follows:

"For arm64, we will only support UEFI for booting with ACPI, hence the 
UEFI GetMemoryMap() boot service is the only mechanism that will be used."

With the patch we tell the UEFI sub-system which memory areas are 
reserved (e.g. for TF-A on ARM or for OpenSBI on RISC-V). This 
information is inferred from the device-tree. The operating system will 
collect this information by calling GetMemoryMap() immediately before 
ExitBootServices().

Without the patch Linux on RISC-V using ACPI crashed when illegally 
accessing the memory reserved for OpenSBI.

Best regards

Heinrich

> 
>> We have to assign EfiReservedMemory
>> according to the prior stage device-tree ($fdtaddr) or as fallback the
>> control device-tree ($fdtcontroladdr).
>>
>> Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt at canonical.com>
>> ---
>>   cmd/bootefi.c           | 25 ++++++++++---------------
>>   lib/efi_loader/Makefile |  2 --
>>   2 files changed, 10 insertions(+), 17 deletions(-)
>>
> 
> The code looks fine, but I would like to better understand why this is needed.
> 
> Regards,
> Simon