[PATCH v3 00/15] Make EFI memory allocations synchronous with LMB
Simon Glass
sjg at chromium.org
Mon Oct 14 17:51:02 CEST 2024
Hi Sughosh,
On Sun, 13 Oct 2024 at 04:55, Sughosh Ganu <sughosh.ganu at linaro.org> 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.
>
>
> Some test logs to highlight the issue that is being fixed by the series.
>
> Without patch series
> --------------------
>
> lmb_dump_all:
> memory.count = 0x1
> memory[0] [0x40000000-0x820fffff], 0x42100000 bytes flags: none
> reserved.count = 0x3
> reserved[0] [0xe100000-0xeffffff], 0x00f00000 bytes flags: no-map
> reserved[1] [0x42000000-0x421fffff], 0x00200000 bytes flags: no-map
> reserved[2] [0x7f77da00-0x820fffff], 0x02982600 bytes flags: no-overwrite
>
>
> => efidebug memmap -- does not show regions allocated by lmb
>
> Missing TPMv2 device for EFI_TCG_PROTOCOL
> Type Start End Attributes
> ================ ================ ================ ==========
> CONVENTIONAL 0000000040000000-000000007f751000 WB
> BOOT DATA 000000007f751000-000000007f756000 WB
> RUNTIME DATA 000000007f756000-000000007f757000 WB|RT
> BOOT DATA 000000007f757000-000000007f758000 WB
> RUNTIME DATA 000000007f758000-000000007f77a000 WB|RT
> BOOT DATA 000000007f77a000-000000007f781000 WB
> BOOT CODE 000000007f781000-00000000807b5000 WB
> RUNTIME DATA 00000000807b5000-00000000807b6000 WB|RT
> BOOT CODE 00000000807b6000-00000000817c0000 WB
> RUNTIME CODE 00000000817c0000-00000000817d0000 WB|RT
> BOOT CODE 00000000817d0000-0000000082100000 WB
> =>
>
>
> Trying to allocate EFI memory with already allocated region succeeds(should fail)
> ---------------------------------------------------------------------------------
>
> => efi_mem alloc 2000 42000000
> Address returned 0x42000000
>
> => efidebug memmap
> Type Start End Attributes
> ================ ================ ================ ==========
> CONVENTIONAL 0000000040000000-0000000042000000 WB
> BOOT DATA 0000000042000000-0000000042002000 WB
> CONVENTIONAL 0000000042002000-000000007f751000 WB
> BOOT DATA 000000007f751000-000000007f756000 WB
> RUNTIME DATA 000000007f756000-000000007f757000 WB|RT
> BOOT DATA 000000007f757000-000000007f758000 WB
> RUNTIME DATA 000000007f758000-000000007f77a000 WB|RT
> BOOT DATA 000000007f77a000-000000007f781000 WB
> BOOT CODE 000000007f781000-00000000807b5000 WB
> RUNTIME DATA 00000000807b5000-00000000807b6000 WB|RT
> BOOT CODE 00000000807b6000-00000000817c0000 WB
> RUNTIME CODE 00000000817c0000-00000000817d0000 WB|RT
> BOOT CODE 00000000817d0000-0000000082100000 WB
> =>
>
>
> With patch series
> -----------------
>
> lmb_dump_all:
> memory.count = 0x1
> memory[0] [0x40000000-0x820fffff], 0x42100000 bytes flags: none
> reserved.count = 0x4
> reserved[0] [0xe100000-0xeffffff], 0x00f00000 bytes flags: no-map
> reserved[1] [0x42000000-0x421fffff], 0x00200000 bytes flags: no-map
> reserved[2] [0x7f77a000-0x7f77cfff], 0x00003000 bytes flags: no-notify, no-overwrite
> reserved[3] [0x7f77da00-0x820fffff], 0x02982600 bytes flags: no-overwrite
>
>
> => efidebug memmap -- now shows the lmb allocated memory regions also
> Missing TPMv2 device for EFI_TCG_PROTOCOL
> Type Start End Attributes
> ================ ================ ================ ==========
> CONVENTIONAL 0000000040000000-0000000042000000 WB
> BOOT DATA 0000000042000000-0000000042200000 WB
> CONVENTIONAL 0000000042200000-000000007f74d000 WB
> BOOT DATA 000000007f74d000-000000007f752000 WB
> RUNTIME DATA 000000007f752000-000000007f753000 WB|RT
> BOOT DATA 000000007f753000-000000007f754000 WB
> RUNTIME DATA 000000007f754000-000000007f776000 WB|RT
> BOOT DATA 000000007f776000-00000000807b5000 WB
> RUNTIME DATA 00000000807b5000-00000000807b6000 WB|RT
> BOOT DATA 00000000807b6000-00000000817c0000 WB
> RUNTIME CODE 00000000817c0000-00000000817d0000 WB|RT
> BOOT DATA 00000000817d0000-0000000082100000 WB
> =>
>
>
> Trying to allocate EFI memory with already allocated region fails as expected
> -----------------------------------------------------------------------------
>
> => efi_mem alloc 2000 42000000
> efi_allocate_pages failed 800000000000000e
> =>
>
> Trying to allocate EFI memory with non-allocated region succeeds
> ----------------------------------------------------------------
>
> => efi_mem alloc 2000 42200000
> Address returned 0x42200000
>
>
> lmb_dump_all:
> memory.count = 0x1
> memory[0] [0x40000000-0x820fffff], 0x42100000 bytes flags: none
> reserved.count = 0x5
> reserved[0] [0xe100000-0xeffffff], 0x00f00000 bytes flags: no-map
> reserved[1] [0x42000000-0x421fffff], 0x00200000 bytes flags: no-map
> reserved[2] [0x42200000-0x42201fff], 0x00002000 bytes flags: no-notify, no-overwrite
> reserved[3] [0x7f74e000-0x7f77cfff], 0x0002f000 bytes flags: no-notify, no-overwrite
> reserved[4] [0x7f77da00-0x820fffff], 0x02982600 bytes flags: no-overwrite
>
> Changes since V2:
> * Use map_to_sysmem() to get the user-visible address to be shared
> with the lmb API's.
> * Fix the wording of some comments in efi_add_known_memory() as
> suggested by Ilias.
> * Rename overlap_no_freemem to overlap_conventional as suggested by
> Ilias.
>
>
>
> Sughosh Ganu (15):
> 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
> efi_memory: do not add U-Boot memory to the 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 | 217 +++++++----------------
> lib/lmb.c | 220 +++++++++++++++++++-----
> 11 files changed, 402 insertions(+), 243 deletions(-)
>
> --
> 2.34.1
>
>
One minor question in my mind with all of this is what exactly is the
status of images. I know that the EFI app itself is considered an
image and is passed into the app. So once the app is finished, the
memory becomes available.
But what about the devicetree? Is that provided as an image? Is it
'boottime data'? Who / what is responsible for deciding when that is
no-longer needed? Does it just fall away as soon as exit-boot-services
is called? What about overlays, logos, or anything else? Some of those
need to be passed to Linux, some don't...
BTW at some point it would be good to have tests for this part of EFI.
E.g. set up some lmb, boot an app in sandbox and check that the
correct memory map appears?
Regards,
SImon
More information about the U-Boot
mailing list