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. > 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 ?) > there is already paravirtualized plumbing in place for the remaining > runtime services. > > Hence my claim earlier that we should cope with the runtime services > pointer being NULL, since that is really the only thing standing in > the way from the kernel side. If you feel that violates the spec in > some way, we could at least conditionalise it on EFI_RUNTIME_SERVICES > having been set already, this gives the Xen code a chance of > overriding them. > -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
