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

[Simon Glass]

Hi Heinrich,

On Sat, 18 Nov 2023 at 10:34, Heinrich Schuchardt
<heinrich.schuchardt at canonical.com> wrote:
>
> 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.

OK thank you, I misunderstood it.

Reviewed-by: Simon Glass <sjg at chromium.org>

Perhaps someone could convert efi_carve_out_dt_rsv() to use the ofnode API?

Regards,
Simon