[PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters

Ard Biesheuvel ard.biesheuvel at linaro.org
Mon Sep 14 03:02:24 PDT 2015


On 14 September 2015 at 11:57, Ian Campbell <ian.campbell at citrix.com> wrote:
> On Mon, 2015-09-14 at 11:43 +0200, Ard Biesheuvel wrote:
>
>> Xen will not boot the kernel via the stub, but directly. It needs to
>> supply a EFI like environment so that the kernel can boot via ACPI.
>> There is no reason whatsoever to mock up boot services or other pieces
>> of UEFI functionality that are not needed.
>
> I'm correct that on native the EFI stub calls ExitBootServices, right?
>
> So the flow for native is:
>
> EFI -> Linux EFI Stub -> Exit Boot Services -> Non-EFI Linux head.S entrypoint
>
> For Xen it is more like:
>
> Xen domain builder -------  ...    ... ------> Non-EFI Linux head.S entrypoint
>
>>  The core kernel does not call any boot services
>
> And it cannot because ExitBootServices has already been called.
>
> I think given all that there should no reason at all for Xen to be
> providing boot services.
>

Indeed.

>>  or SetVirtualAddressMap/ConvertPointer, and
>
> These two are RTS, so in principal it could.
>
> (I'm not sure about ConvertPointer, is it useful for OS kernels, or just
> for "UEFI components" mentioned at http://wiki.phoenix.com/wiki/index.php/E
> FI_RUNTIME_SERVICES#ConvertPointer.28.29 ?)
>

No, there is no point. The stub calls SetVirtualAddressMap, so the
kernel proper can never call it, since it can only be called once.
ConvertPointer has little utility outside of the UEFI runtime
components that are invoked during SetVirtualAddressMap, so I don't
see a reason to supply that either.

-- 
Ard.



More information about the linux-arm-kernel mailing list