Re: [Xen-devel] Is: Wrap-up Was: Re: EFI and multiboot2 devlopment work for Xen

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Wed, 30 Oct 2013, Daniel Kiper wrote:
> Hi,
> 
> Here is a short summary of our discussion. It looks
> that we have two choices right now:
>   - chainloader,
>   - multiboot2 protocol.
> 
> chainloader solution could be implemented quite easily. Some code should be
> added for command line parsing. However, all arguments for Xen itself and
> modules must be passed as single line with special separators (e.g. ///;
> correct me if I am wrong). This thing makes that solution not very convenient,
> especially if you would like to edit boot command line directly from boot
> loader. chainloader will support PE images directly. However, it could load
> only PE image with Xen. Xen image should load all other parts but they could
> be loaded from FAT filesystem only. This works because it was implemented
> in original Xen EFI implementation. Support for secure boot and shim loader
> could be added. It was implemented by SUSE guys and is available in latest 
> SUSE
> distros. However, it is not merged into GRUB2 upstream (like linuxefi). I do
> not know what are GRUB2 and SUSE guys plans to upstream this solution.
> 
> multiboot2 protocol requires some more changes. However, about 80% of code
> is ready. In this case Xen and modules are loaded by GRUB2 itself. It means
> that all images could be placed on any filesystem recognized by GRUB2. Options
> for Xen and modules are passed separately which simplifies command line 
> editing
> in boot loader and parsing. multiboot2 protocol is very flexible and could be
> easily extended in the future if a need arises. Support for secure boot and
> shim loader could be added. However, it was not implemented yet. Probably
> linuxefi module could be used as a reference or even as a base for 
> development.
> However, I do not know are there plans to support such solution by GRUB2
> community. Currently, support for native PE images signatures and GPG 
> signatures
> is under development for GRUB2 upstream.

FYI on ARM it is possible to load a kernel as PE but at the same time
passing additional info as where the initrd or other additional binaries
have been loaded or even command line arguments. These info are passed
from the bootloader to the kernel via Device Tree.  Grant (CC'ed) might
be able to add additional details on where the code actually lives.

So on ARM I expect that we won't be needing multiboot2 after all, our
small multiboot-module protocol
(http://code.metager.de/source/xref/xen/docs/misc/arm/device-tree/booting.txt)
should be sufficient.


> Personally I prefer multiboot2 protocol solution because it is much
> more flexible and easier for use (even if it is more difficult to
> implement).

on x86 makes sense


> There is still open question that ExitBootServices() should be called by GRUB2
> loader or by loaded image itself on EFI platform. UEFI spec 2.4 states in many
> places that it is "OS loader" or "Operating System" responsibility. However,
> I think that "OS loader" should be understood as a integral piece of 
> "Operating
> System" responsible for its load into memory without usage of any additional
> loader like GRUB2. So in this situation it looks that "Operating System" 
> should
> call ExitBootServices() on EFI platforms instead of GRUB2. Even if we agree 
> that
> this assumption is wrong I think that it is better to give an "Operating 
> System"
> a choice to use boot services. This way OS could decide which source of 
> information
> is more convenient in its case, do extra things with EFI platform support 
> (e.g.
> get memory map directly from EFI) and call ExitBootServices() in relevant 
> time.

I agree


> There is also third solution for issues with ExitBootServices(). In case
> of multiboot2 protocol OS could request that EFI should be left as is.
> Solution was proposed by Vladimir and I think that it makes sense. However,
> this does not solve problem with ExitBootServices() in case of other
> boot loaders/protocols. So we should take a decision accordingly to above
> considerations in regards to linux, chainloader and similar stuff.
 


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