Re: [Xen-devel] [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters

[Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>]

On 14 September 2015 at 11:57, Ian Campbell <ian.campbell@xxxxxxxxxx> 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.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel