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. Thanks Dave
