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 = &params->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


Reply via email to