mbox series

[v2,00/14] Make EFI memory allocations synchronous with LMB

Message ID 20241008181435.1753814-1-sughosh.ganu@linaro.org
Headers show
Series Make EFI memory allocations synchronous with LMB | expand

Message

Sughosh Ganu Oct. 8, 2024, 6:14 p.m. UTC 
This is part two of the series to have the EFI and LMB modules have a
coherent view of memory. Part one of this goal was to change the LMB
module to have a global and persistent memory map. Those patches have
now been applied to the next branch.

These patches are changing the EFI memory allocation API's such that
they rely on the LMB module to allocate RAM memory. This fixes the
current scenario where the EFI memory module has no visibility of the
allocations/reservations made by the LMB module. One thing to note
here is that this is limited to the RAM memory region, i.e. the
EFI_CONVENTIONAL_MEMORY type. Any other memory type that is to be
added to the EFI memory map, still gets handled by the EFI memory
module.


Changes since V1:
* Add comments for the API's added
* Add a config for SPL stage
* Call the efi_add_memory_map_pg() function directly from the
  lmb_map_update_notify() instead of doing it through the event
  framework.
* Call the efi_add_memory_map_pg() with overlap_only_ram argument set
  to false, to allow for overlapping allocation design of LMB.
* Use the return value of lmb_map_update_notify() at it's call sites
* Do not remove the inclusion of efi_loader.h as it is now needed for
  the lmb_map_update_notify()


Sughosh Ganu (14):
  lmb: add versions of the lmb API with flags
  lmb: add a flag to allow suppressing memory map change notification
  efi: memory: use the lmb API's for allocating and freeing memory
  lib: Kconfig: add a config symbol for getting lmb memory map updates
  add a function to check if an address is in RAM memory
  lmb: notify of any changes to the LMB memory map
  ti: k3: remove efi_add_known_memory() function definition
  stm32mp: remove efi_add_known_memory() function definition
  lmb: allow for boards to specify memory map
  layerscape: use the lmb API's to add RAM memory
  x86: e820: use the lmb API for adding RAM memory
  efi_memory: do not add RAM memory to the memory map
  lmb: remove call to efi_lmb_reserve()
  efi_memory: rename variable to highlight overlap with free memory

 arch/arm/cpu/armv8/fsl-layerscape/cpu.c |   8 +-
 arch/arm/mach-k3/common.c               |  11 --
 arch/arm/mach-stm32mp/dram_init.c       |  11 --
 arch/x86/lib/e820.c                     |  47 +++--
 common/board_r.c                        |   5 +
 include/efi_loader.h                    |  27 ++-
 include/lmb.h                           |  61 +++++++
 lib/Kconfig                             |  36 ++++
 lib/efi_loader/Kconfig                  |   2 +
 lib/efi_loader/efi_memory.c             | 202 ++++++----------------
 lib/lmb.c                               | 220 +++++++++++++++++++-----
 11 files changed, 398 insertions(+), 232 deletions(-)

Comments

Heinrich Schuchardt Oct. 8, 2024, 7:41 p.m. UTC | #1 
On 10/8/24 20:14, Sughosh Ganu wrote:
> This is part two of the series to have the EFI and LMB modules have a
> coherent view of memory. Part one of this goal was to change the LMB
> module to have a global and persistent memory map. Those patches have
> now been applied to the next branch.
>
> These patches are changing the EFI memory allocation API's such that
> they rely on the LMB module to allocate RAM memory. This fixes the
> current scenario where the EFI memory module has no visibility of the
> allocations/reservations made by the LMB module. One thing to note
> here is that this is limited to the RAM memory region, i.e. the
> EFI_CONVENTIONAL_MEMORY type. Any other memory type that is to be
> added to the EFI memory map, still gets handled by the EFI memory
> module.

LMB seems to have restrictions that EFI does not have:

__lmb_free() fails if the freed memory range extends over multiple
adjacent allocated regions.

FreePages() in the EFI specification does not require that all freed
pages have the same properties.

I don't think this will hit us with this series as we currently always
pass the same flags to LMB when allocating and LMB should be coalescing
adjacent allocations.

But if we will go forward and move the EFI memory map into LMB to avoid
double accounting we will have to rework __lmb_free().

Best regards

Heinrich
Heinrich Schuchardt Oct. 8, 2024, 9:48 p.m. UTC | #2 
On 10/8/24 20:14, Sughosh Ganu wrote:
> This is part two of the series to have the EFI and LMB modules have a
> coherent view of memory. Part one of this goal was to change the LMB
> module to have a global and persistent memory map. Those patches have
> now been applied to the next branch.
>
> These patches are changing the EFI memory allocation API's such that
> they rely on the LMB module to allocate RAM memory. This fixes the
> current scenario where the EFI memory module has no visibility of the
> allocations/reservations made by the LMB module. One thing to note
> here is that this is limited to the RAM memory region, i.e. the
> EFI_CONVENTIONAL_MEMORY type. Any other memory type that is to be
> added to the EFI memory map, still gets handled by the EFI memory
> module.

With this series the UEFI SCT fails in the MemoryAllocationServicesTest
on arm64 when running on sandbox64_defconfig:

UEFI image [0x00000000182e5000:0x00000000183b7fff] pc=0x99d4out of
memory 'c=0x99d4
UEFI image [0x0000000014139000:0x000000001416dfff]out of memory
'0x0000000014139000:0x000000001416dfff]
UEFI image [0x00000000140fc000:0x0000000014100fff]out of memory
'0x00000000140fc000:0x0000000014100fff]

Without this series the test runs fine.

Some guidance for running the SCT is provided in
https://github.com/U-Boot-EFI/u-boot-sct-results.

Best regards

Heinrich