All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Rapoport <rppt@kernel.org>
To: Ard Biesheuvel <ardb+git@google.com>
Cc: linux-kernel@vger.kernel.org, linux-efi@vger.kernel.org,
	x86@kernel.org, Ard Biesheuvel <ardb@kernel.org>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Dave Young <ruirui.yang@linux.dev>,
	Gregory Price <gourry@gourry.net>
Subject: Re: [PATCH v3 05/17] x86/efi: Simplify real mode trampoline allocation quirk
Date: Tue, 28 Apr 2026 10:32:51 +0200	[thread overview]
Message-ID: <afBws32wHp4Cgrgj@kernel.org> (raw)
In-Reply-To: <20260423152024.1098465-24-ardb+git@google.com>

On Thu, Apr 23, 2026 at 05:20:30PM +0200, Ard Biesheuvel wrote:
> From: Ard Biesheuvel <ardb@kernel.org>
> 
> To work around a common bug in EFI firmware for x86 systems, Linux
> reserves all EFI boot services code and data regions until after it has
> invoked the SetVirtualAddressMap() EFI runtime service. This is needed
> because those regions may still be accessed by the firmware during that
> call, even though the EFI spec says that they shouldn't.
> 
> This includes any boot services data regions below 1M, which might mean
> that by the time the real mode trampoline is being allocated, all memory
> below 1M is already exhausted.
> 
> Commit
> 
>   5bc653b73182 ("x86/efi: Allocate a trampoline if needed in efi_free_boot_services()")
> 
> added a quirk to detect this condition, and to make another attempt at
> allocating the real mode trampoline when freeing those boot services
> regions again. This is a rather crude hack, which gets in the way of
> cleanup work on the EFI/x86 memory map handling code.
> 
> Given that
> 
> - the real mode trampoline is normally allocated soon after all EFI boot
>   services regions are reserved temporarily,
> - this allocation logic marks all memory below 1M as reserved,
> - the trampoline memory is not actually populated until an early
>   initcall,
> 
> there is actually no need to reserve any boot services regions below 1M,
> even if they are mapped into the EFI page tables during the call to
> SetVirtualAddressMap(). So cap the lower bound of the reserved regions
> to 1M, and fix up the size accordingly when making the reservation. This
> allows the additional quirk to be dropped entirely.
> 
> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
> ---
>  arch/x86/platform/efi/quirks.c | 34 ++++----------------
>  1 file changed, 6 insertions(+), 28 deletions(-)
> 
> diff --git a/arch/x86/platform/efi/quirks.c b/arch/x86/platform/efi/quirks.c
> index e2e57e9201a9..e79fb94c1bf6 100644
> --- a/arch/x86/platform/efi/quirks.c
> +++ b/arch/x86/platform/efi/quirks.c
> @@ -324,10 +324,14 @@ void __init efi_reserve_boot_services(void)
>  		return;
>  
>  	for_each_efi_memory_desc(md) {
> -		u64 start = md->phys_addr;
> -		u64 size = md->num_pages << EFI_PAGE_SHIFT;
> +		u64 start = max(md->phys_addr, SZ_1M);

A comment that says that we don't reserve regions below 1M because they are
reserved elsewhere would be nice here. Other that that

Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org>

> +		u64 end = md->phys_addr + (md->num_pages << EFI_PAGE_SHIFT);
> +		u64 size = end - start;
>  		bool already_reserved;
>  
> +		if (end <= start)
> +			continue;
> +
>  		if (md->type != EFI_BOOT_SERVICES_CODE &&
>  		    md->type != EFI_BOOT_SERVICES_DATA)
>  			continue;

-- 
Sincerely yours,
Mike.

  reply	other threads:[~2026-04-28  8:32 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-23 15:20 [PATCH v3 00/17] efi/x86: Avoid the need to mangle the EFI memory map Ard Biesheuvel
2026-04-23 15:20 ` [PATCH v3 01/17] x86/efi: Omit redundant kernel image overlap check Ard Biesheuvel
2026-04-28  8:21   ` Mike Rapoport
2026-04-28 10:40   ` Gregory Price
2026-04-23 15:20 ` [PATCH v3 02/17] x86/efi: Drop redundant EFI_PARAVIRT check Ard Biesheuvel
2026-04-28  8:21   ` Mike Rapoport
2026-04-28 10:42   ` Gregory Price
2026-04-23 15:20 ` [PATCH v3 03/17] x86/efi: Only merge EFI memory map entries on 32-bit systems Ard Biesheuvel
2026-04-28 10:47   ` Gregory Price
2026-04-23 15:20 ` [PATCH v3 04/17] x86/efi: Defer sub-1M check from unmap to free stage Ard Biesheuvel
2026-04-28  8:25   ` Mike Rapoport
2026-04-23 15:20 ` [PATCH v3 05/17] x86/efi: Simplify real mode trampoline allocation quirk Ard Biesheuvel
2026-04-28  8:32   ` Mike Rapoport [this message]
2026-04-23 15:20 ` [PATCH v3 06/17] x86/efi: Unmap kernel-reserved boot regions from EFI page tables Ard Biesheuvel
2026-04-23 15:20 ` [PATCH v3 07/17] x86/efi: Drop EFI_MEMORY_RUNTIME check from __ioremap_check_other() Ard Biesheuvel
2026-04-23 15:20 ` [PATCH v3 08/17] x86/efi: Allow ranges_to_free array to grow beyond initial size Ard Biesheuvel
2026-04-28  8:38   ` Mike Rapoport
2026-04-23 15:20 ` [PATCH v3 09/17] x86/efi: Intersect ranges_to_free with MEMBLOCK_RSRV_KERN regions Ard Biesheuvel
2026-04-28  8:40   ` Mike Rapoport
2026-04-23 15:20 ` [PATCH v3 10/17] x86/efi: Do not rely on EFI_MEMORY_RUNTIME bit and avoid entry splitting Ard Biesheuvel
2026-04-23 15:20 ` [PATCH v3 11/17] efi: Use nr_map not map_end to find the last valid memory map entry Ard Biesheuvel
2026-04-23 15:20 ` [PATCH v3 12/17] x86/efi: Clean the memory map using iterator and filter API Ard Biesheuvel
2026-04-23 15:20 ` [PATCH v3 13/17] x86/efi: Update the runtime map in place Ard Biesheuvel
2026-04-23 15:20 ` [PATCH v3 14/17] x86/efi: Reuse memory map instead of reallocating it Ard Biesheuvel
2026-04-23 15:20 ` [PATCH v3 15/17] x86/efi: Merge two traversals of the memory map when freeing boot regions Ard Biesheuvel
2026-04-23 15:20 ` [PATCH v3 16/17] x86/efi: Avoid EFI_MEMORY_RUNTIME for early EFI boot memory reservations Ard Biesheuvel
2026-04-23 15:20 ` [PATCH v3 17/17] x86/efi: Drop kexec quirk for the EFI memory attributes table Ard Biesheuvel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=afBws32wHp4Cgrgj@kernel.org \
    --to=rppt@kernel.org \
    --cc=ardb+git@google.com \
    --cc=ardb@kernel.org \
    --cc=benh@kernel.crashing.org \
    --cc=gourry@gourry.net \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ruirui.yang@linux.dev \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.