u-boot.git/lib/efi_loader/efi_memory.c, branch v2025.07

efi_loader: allow for removal of memory from the EFI map

2025-03-26T11:28:08+00:00

With upcoming changes supporting pmem nodes, we need to remove the
pmem area from the EFI memory map. Rename efi_add_memory_map_pg() to
efi_update_memory_map(), and allow removing memory from the EFI memory
map.

Signed-off-by: Sughosh Ganu 
Signed-off-by: Ilias Apalodimas

lmb: change the return code on lmb_alloc_addr()

2025-03-24T17:12:33+00:00

Ben reports a failure to boot the kernel on hardware that starts its
physical memory from 0x0.
The reason is that lmb_alloc_addr(), which is supposed to reserve a
specific address, takes the address as the first argument, but then also
returns the address for success or failure and treats 0 as a failure.

Since we already know the address change the prototype to return an int.

Reported-by: Ben Schneider 
Signed-off-by: Ilias Apalodimas 
Tested-by: Ben Schneider 
Reviewed-by: Sughosh Ganu

efi_loader: make efi_add_memory_map_pg() static

2025-02-20T10:09:33+00:00

The function is only used in the efi_memory.c module.

Reviewed-by: Ilias Apalodimas 
Signed-off-by: Heinrich Schuchardt

lmb: move lmb_map_update_notify() to EFI

2025-02-20T10:09:33+00:00

When building with qemu_arm64_defconfig with CONFIG_CC_OPTIMIZE_FOR_DEBUG=y
and CONFIG_EFI_LOADER=n an error undefined reference to efi_add_memory_map_pg
occurs.

Move the EFI dependent part of lmb_map_update_notify() to the EFI
sub-system.

Reported-by: Liya Huang <1425075683@qq.com>
Acked-by: Liya Huang <1425075683@qq.com>
Signed-off-by: Heinrich Schuchardt

lmb: Remove lmb_alloc_base_flags()

2024-12-30T19:21:55+00:00

lmb_alloc_base() is just calling lmb_alloc_base_flags() with LMB_NONE.
There's not much we gain from this abstraction, so let's remove the
former add the flags argument to lmb_alloc_base() and make the code
a bit easier to follow.

Reviewed-by: Sam Protsenko 
Tested-by: Sam Protsenko 
Signed-off-by: Ilias Apalodimas

lmb: Remove lmb_alloc_addr_flags()

2024-12-30T19:21:55+00:00

lmb_alloc_addr() is just calling lmb_alloc_addr_flags() with LMB_NONE
There's not much we gain from this abstraction, so let's remove the
latter, add a flags argument to lmb_alloc_addr() and make the code a
bit easier to follow.

Reviewed-by: Sam Protsenko 
Tested-by: Sam Protsenko 
Signed-off-by: Ilias Apalodimas

Revert "efi_memory: do not add U-Boot memory to the memory map"

2024-11-30T14:37:53+00:00

This reverts commit ("commit a68c9ac5d8af ("efi_memory: do not add
U-Boot memory to the memory map").

This code was removed when the EFI subsystem started using LMB calls for
the reservations. In hindsight it unearthed two problems.

The e820 code is adding u-boot memory as EfiReservedMemory while it
should look at what LMB added and decide instead of blindly overwriting
it. The reason this worked is that we marked that code properly late,
when the EFI came up. But now with the LMB changes, the EFI map gets
added first and the e820 code overwrites it.

The second problem is that we never mark SetVirtualAddressMap as runtime
code, which we should according to the spec. Until we fix this the
current hack can't go away, at least for architectures that *need* to
call SVAM.

More specifically x86 currently requires SVAM and sets the NX bit for
pages not marked as *_CODE. So unless we do that late, it will crash
trying to execute from non-executable memory. It's also worth noting
that x86 calls SVAM late in the boot, so this will work until someone
decides to overwrite/use BootServicesCode from the OS.

Notably arm64 disables it explicitly if the VA space is > 48bits, so
doesn't suffer from any of these problems.

This doesn't really deserve a fixes tag, since it brings back a hack to
remedy a situation that was wrong long before that commit, but in case
anyone hits the same bug ...
Simon sent the original revert in the link, but we need a proper
justification for it.

Link: https://lore.kernel.org/u-boot/20241112131830.576864-1-sjg@chromium.org/
Signed-off-by: Ilias Apalodimas 
Acked-by: Sughosh Ganu 
Reported-by: Simon Glass

lmb: Correctly unmap and free memory on errors

2024-11-24T14:25:03+00:00

We never free and unmap the memory on errors and we never unmap it when
freeing it. The latter won't cause any problems even on sandbox, but for
consistency always use unmap_sysmem()

Fixes: commit 22f2c9ed9f53 ("efi: memory: use the lmb API's for allocating and freeing memory")
Reviewed-by: Heinrich Schuchardt 
Signed-off-by: Ilias Apalodimas

efi_loader: Simplify efi_free_pages()

2024-10-30T20:44:38+00:00

We currently call efi_free_pages() with a notify flag and explicitly
update the efi memory map. That's not needed as lmb_free_flags() will do
that for us if the LMB_NONOTIFY flag is removed

Signed-off-by: Ilias Apalodimas 
Reviewed-by: Heinrich Schuchardt

lmb: Remove lmb_alloc_flags()

2024-10-29T22:17:47+00:00

lmb_alloc_flags() & lmb_alloc_base_flags() are just a wrappers for
_lmb_alloc_base(). Since the only difference is the max address of the
allowed allocation which _lmb_alloc_base() already supports with the
LMB_ALLOC_ANYWHERE flag, remove one of them.

Keep the lmb_alloc_base_flags() which also prints an error on failures
and adjust efi_allocate_pages() to only use one of them.

While at it clean up the duplicate function description from the header
file.

Signed-off-by: Ilias Apalodimas