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

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

efi_loader: add missing lf in error message

2024-10-18T15:05:12+00:00

Messages written with log_err() should terminate with a linefeed.

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

efi_memory: rename variable to highlight overlap with free memory

2024-10-15T19:45:30+00:00

The variable overlap_only_ram is used to specify that the new memory
region that is being created needs to come from the free memory pool
-- this is done by carving out the memory region from the free
memory. The name is a bit confusing though, as other allocated memory
regions, like boot-services code and data are also part of the RAM
memory. Rename the variable to overlap_conventional to highlight the
fact that it is the free/conventional memory that is being referred to
in this context.

Signed-off-by: Sughosh Ganu 
Reviewed-by: Ilias Apalodimas 
Reviewed-by: Simon Glass

efi_memory: do not add RAM memory to the memory map

2024-10-15T19:45:30+00:00

The EFI_CONVENTIONAL_MEMORY type, which is the usable RAM memory is
now being managed by the LMB module. Remove the addition of this
memory type to the EFI memory map. This memory now gets added to the
EFI memory map as part of the LMB memory map update event handler.

Signed-off-by: Sughosh Ganu 
Reviewed-by: Simon Glass 
Reviewed-by: Ilias Apalodimas

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

2024-10-15T19:45:29+00:00

The memory region occupied by U-Boot is reserved by LMB, and gets
added to the EFI memory map through a call from the LMB module. Remove
this superfluous addition to the EFI memory map.

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

lmb: notify of any changes to the LMB memory map

2024-10-15T19:45:29+00:00

In U-Boot, LMB and EFI are two primary modules who provide memory
allocation and reservation API's. Both these modules operate with the
same regions of memory for allocations. Use the LMB memory map update
event to notify other interested listeners about a change in it's
memory map. This can then be used by the other module to keep track of
available and used memory.

There is no need to send these notifications when the LMB module is
being unit-tested. Add a flag to the lmb structure to indicate if the
memory map is being used for tests, and suppress sending any
notifications when running these unit tests.

Signed-off-by: Sughosh Ganu

efi: memory: use the lmb API's for allocating and freeing memory

2024-10-15T19:45:29+00:00

Use the LMB API's for allocating and freeing up memory. With this, the
LMB module becomes the common backend for managing non U-Boot image
memory that might be requested by other modules.

Signed-off-by: Sughosh Ganu