Re: [PATCH] x86/boot: Use 5-level paging trampoline in place if possible

[Kiryl Shutsemau]

On Wed, Mar 04, 2026 at 05:05:50PM +0100, Ard Biesheuvel wrote:
> The traditional x86 decompressor contains a rather nasty hack in
> find_trampoline_placement() to temporarily use some system RAM below 1M
> for a 32-bit addressable trampoline, which it needs in order to be able
> to switch from 4 levels of paging to 5 or vice versa.
> 
> It does this even when running from 32-bit addressable memory itself, in
> which case none of this is needed - the trampoline code can be fixed up
> to execute correctly from anywhere below 4G, and so it can execute in
> place from the decompressor's initial placement. The additional root
> level page table allocation can be used directly if it resides below the
> 4G mark as well.
> 
> The traditional decompressor is no longer used by the EFI stub, and is
> mostly relied upon by non-EFI bootloaders such as coreboot which run
> entirely in 32-bit mode, and are therefore guaranteed to place the
> decompressor in 32-bit addressable memory. In those cases, on CPUs that
> support it, 5-level paging will always get enabled, by invoking this
> code (unless it is explicitly disabled on the command line) but the
> trampoline allocation is never needed.
> 
> kexec also relies on the traditional decompressor and does typically
> load the kernel above 4G, but in that case, the trampoline is only
> needed when either the first or the second kernel explicitly disables
> 5-level paging, otherwise it will just remain enabled and no trampoline
> is needed.
> 
> So avoid the trampoline hack unless it is really required.

My worry is that the trampoline hack code will not get proper testing if
it only runs in marginal cases. And will rot over time. I intentionally
made it unconditional to avoid it.

-- 
  Kiryl Shutsemau / Kirill A. Shutemov