[PATCH v4 0/9] Adjust initial EFI memory-allocation to be in the U-Boot region

[Simon Glass]

Hi,

On Sat, 2 Nov 2024 at 18:29, Simon Glass <sjg at chromium.org> wrote:
>
> U-Boot relocates itself to the top of memory and is supposed to avoid
> using any memory below that region. This allows the maximum amount of
> memory to be available for loading images.
>
> The lmb subsystem automatically protects U-Boot's code and data from
> being overwritten. It relies on this region being a contiguous area of
> memory. This setup has worked well for at least 15 years and has been
> documented in the README for as long.
>
> The EFI_LOADER subsystem currently uses memory outside the U-Boot region
> when starting up.
>
> Some of the downstream problems this causes are:
>
> 1. It can overwrite images that have been loaded
> 2. Requires lmb reservations to avoid (1) even if EFI_LOADER is not
>    being used
> 3. Uses regions which scripts expect to be available, e.g. the existing
>    kernel_addr_r variables
> 4. Introduces confusion as to what memory U-Boot can use for itself
>
> This series sets up a very small region of memory which EFI can used at
> start-up, thus avoiding touching memory outside the U-Boot region.
>
> There are still a few tables which are not in the bloblist, but that
> will be resolved separately.
>
> Other than tables, the amount of API-visible memory allocated by EFI
> before booting is actually very small: 3 allocations, of a total of
> about 250 bytes. However, there are some areas where EFI allocations are
> done unnecessarily. For example efi_disk_add_dev() uses page-allocation
> to allocate an efi_device_path, then immediately frees it again. In this
> case it would be better to use malloc(). Since each allocation consumes
> a page (4KB), 256KB has been chosen for the size here, enough for 64
> allocations.
>
> As soon as efi_init_obj_list() is called, we know that the EFI subsystem
> is to be used, so we can relax the restrictions and allow EFI to use any
> memory it likes. This is handled using a simple boolean flag in BSS, since
> it cannot happen before relocation.
>
> Changes in v5:
> - Drop the word 'warning'
>
> Changes in v4:
> - Expand the commit message
> - Reword the commit message since this feature is needed
> - Use a different technique to keep the memory-usage in place
> - Drop changes to pool allocation
> - Reorder the patches
> - Rewrite the cover letter
> - Make it a debug message for now
>
> Changes in v3:
> - Add new patch to drop the memset() from efi_alloc()
> - Drop patch to convert device_path allocation to use malloc()
>
> Changes in v2:
> - Drop patch 'Show more information in efi index'
> - Drop patch 'Avoid pool allocation in efi_get_memory_map_alloc()'
> - Add the word 'warning', use log_warning() and show the end address
>
> Simon Glass (9):
>   kernel: Document ALIGN macros
>   board_f: Correct stack reservation
>   board_f: Rename reserve_stack_aligned()
>   efi: Drop the memset() from efi_alloc()
>   efi: Show the location of the bounce buffer when debugging
>   event: Add a generic way to reserve memory
>   efi: Reserve some memory for initial use
>   efi: Keep early allocations to the U-Boot region
>   wip
>
>  cmd/meminfo.c                     |  7 +++
>  common/board_f.c                  | 15 ++---
>  common/event.c                    |  1 +
>  include/asm-generic/global_data.h | 28 +++++++++
>  include/efi_loader.h              | 33 ++++++++++-
>  include/event.h                   | 11 ++++
>  include/linux/kernel.h            | 31 ++++++++++
>  include/lmb.h                     | 12 ++++
>  lib/efi_loader/efi_bootbin.c      |  9 +++
>  lib/efi_loader/efi_memory.c       | 98 +++++++++++++++++++++++++++++--
>  lib/efi_loader/efi_setup.c        |  5 ++
>  lib/lmb.c                         | 12 ++++
>  test/py/tests/test_event_dump.py  |  1 +
>  13 files changed, 249 insertions(+), 14 deletions(-)

Ignore this, sent by mistake due to my getting confused by a flaky
internet connection.

Regards,
Simon