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

[Simon Glass]

Hi Heinrich,

On Sat, 18 Nov 2023 at 16:06, Heinrich Schuchardt
<heinrich.schuchardt at canonical.com> wrote:
>
> On 11/18/23 18:58, Simon Glass wrote:
> > 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?
>
> Is there any ofnode API to retrieve reservations as easily as with
> fdt_get_mem_rsv(), fdt_num_mem_rsv()?

Not yet :-)

>
> boot/image-fdt.c, boot/fdt_region.c, boot/fdt_support.c, cmd/fdt.c all
> use the libfdt API directly.

Yes, but it is starting to change. Ultimately we will likely use
livetree for fixups due to efficiency.

Regards,
Simon