On Fri, Mar 06, 2026 at 04:57:06PM +0100, Ard Biesheuvel wrote:
> From: Ard Biesheuvel <ardb@kernel.org>
>
> By definition, EFI memory regions of type boot services code or data
> have no special significance to the firmware at runtime, only to the OS.
> In some cases, the firmware will allocate tables and other assets that
> are passed in memory in regions of this type, and leave it up to the OS
> to decide whether or not to treat the allocation as special, or simply
> consume the contents at boot and recycle the RAM for ordinary use. The
> reason for this approach is that it avoids needless memory reservations
> for assets that the OS knows nothing about, and therefore doesn't know
> how to free either.
>
> This means that any memblock reservations covering such regions can be
> marked as MEMBLOCK_RSRV_KERN - this is a better match semantically, and
> is useful on x86 to distinguish true reservations from temporary
> reservations that are only needed to work around firmware bugs.
>
> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
> ---
> drivers/firmware/efi/efi.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
> index b2fb92a4bbd1..e4ab7481bbf6 100644
> --- a/drivers/firmware/efi/efi.c
> +++ b/drivers/firmware/efi/efi.c
> @@ -600,7 +600,9 @@ void __init efi_mem_reserve(phys_addr_t addr, u64 size)
> return;
>
> if (!memblock_is_region_reserved(addr, size))
> - memblock_reserve(addr, size);
> + memblock_reserve_kern(addr, size);
> + else
> + memblock_reserved_mark_kern(addr, size);
>
> /*
> * Some architectures (x86) reserve all boot services ranges
> --
> 2.53.0.473.g4a7958ca14-goog
>
--
Sincerely yours,
Mike.