On Thu, 19 Feb 2026, at 07:57, Dave Young wrote: > Hi Ard, > >> Actually, looking at that code more closely, I kind of wonder why the kexec >> code tests for EFI_RUNTIME_SERVICES to begin with. Perhaps it might be >> sufficient to do this: >> >> diff --git a/arch/x86/kernel/kexec-bzimage64.c >> b/arch/x86/kernel/kexec-bzimage64.c >> index c3244ac680d1..bec91ee7e668 100644 >> --- a/arch/x86/kernel/kexec-bzimage64.c >> +++ b/arch/x86/kernel/kexec-bzimage64.c >> @@ -192,7 +192,7 @@ setup_efi_state(struct boot_params *params, unsigned >> long params_load_addr, >> struct efi_info *current_ei = &boot_params.efi_info; >> struct efi_info *ei = ¶ms->efi_info; >> >> - if (!efi_enabled(EFI_RUNTIME_SERVICES)) >> + if (!efi_enabled(EFI_MEMMAP)) >> return 0; >> >> if (!current_ei->efi_memmap_size) >> >> That way, if the first kernel was booted via EFI but without runtime >> services enabled, the kexec'ed kernel will simply inherit the ACPI and EFI >> tables. > > Actually it does not work, EFI_MEMMAP is unset in function > efi_memmap_unmap() when runtime is disabled, so nodifference for > checking EFI_MEMMAP or EFI_RUNTIME_SERVICES bits. > > The x86 kexec efi code is simply written to assume EFI runtime is > enabled as it copies the cooked runtime service mem ranges in memmap. > If we want to improve it I suspect the efi initialization code could > need changes, and then even if first kernel disabled runtime, the > kexec 2nd kernel still have chance to enter virtual mode to enable > runtime. But this does requires more work to be done. >
Yeah, fixing that seems a bit risky, and not really worth the reward.
