Re: [Xen-devel] [Linaro-uefi] [PATCH] xen: arm: implement generic multiboot compatibility strings (Was: Re: The GRUB multiboot support patch for aarch64(V3.1))

[Ian Campbell <ijc@xxxxxxxxxxxxxx>]

On Thu, 2014-06-05 at 18:03 +0100, Julien Grall wrote:
> On 06/05/2014 05:55 PM, Ian Campbell wrote:
> > On Thu, 2014-06-05 at 17:36 +0100, Julien Grall wrote:
> >> Hi Ian,
> >>
> >> On 06/05/2014 12:56 PM, Ian Campbell wrote:
> >>> On Thu, 2014-06-05 at 15:46 +0800, Fu Wei wrote:
> >>>>> I can see why you did this (it's what Xen actually supports today) but I
> >>>>> wonder if in the interests of reducing the special cases I should create
> >>>>> a Xen patch which causes it to accept both names so that you can just
> >>>>> implement the "multiboot,*" stuff in common code without the special
> >>>>> cases? (Although that depends on the reason for the other non-compat
> >>>>> string special cases too)
> >>>>
> >>>> I think the "multiboot,*" stuff will be better, once Xen supports
> >>>> this, I will update this code.
> >>>
> >>> I've only compile tested this, but I *think* this does the right thing.
> >>>
> >>> Ian.
> >>>
> >>> 8<-----------------
> >>>
> >>> From d0acce53a086869420c2d8870d1a8a058013d6b5 Mon Sep 17 00:00:00 2001
> >>> From: Ian Campbell <ian.campbell@xxxxxxxxxx>
> >>> Date: Wed, 4 Jun 2014 18:17:10 +0100
> >>> Subject: [PATCH] xen: arm: implement generic multiboot compatibility 
> >>> strings
> >>>
> >>> This causes Xen to accept the more generic names originally proposed by
> >>> Andre in http://thread.gmane.org/gmane.linux.linaro.announce.boot/326 and
> >>> incorporated into the proposal in
> >>> http://wiki.xen.org/wiki/Xen_ARM_with_Virtualization_Extensions/Multiboot
> >>>
> >>> This will allow bootloaders to not special case Xen (or at least to reduce
> >>> the amount which is required).
> >>>
> >>> Signed-off-by: Ian Campbell <ian.campbell@xxxxxxxxxx>
> >>> ---
> >>>  xen/common/device_tree.c | 9 ++++++---
> >>>  1 file changed, 6 insertions(+), 3 deletions(-)
> >>>
> >>> diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
> >>> index f0b17a3..5040097 100644
> >>> --- a/xen/common/device_tree.c
> >>> +++ b/xen/common/device_tree.c
> >>> @@ -338,9 +338,11 @@ static void __init process_multiboot_node(const void 
> >>> *fdt, int node,
> >>>      struct dt_mb_module *mod;
> >>>      int len;
> >>>  
> >>> -    if ( fdt_node_check_compatible(fdt, node, "xen,linux-zimage") == 0 )
> >>> +    if ( fdt_node_check_compatible(fdt, node, "xen,linux-zimage") == 0 ||
> >>> +         fdt_node_check_compatible(fdt, node, "multiboot,linux-zimage") 
> >>> == 0 )
> >>
> >> While we are modifying the protocol, "linux-zImage" is confusing in the
> >> name. Actually we can use it for an ELF, another OS... I don't think Xen
> >> will change his behavior depending of the DOM0 image.
> > 
> > zImage defines the boot protocol to use. Since the protocol is defined
> > by Linux as zImage I think that is the appropriate name, if some other
> > OS wants to mimic Linux then fine. But if we end up supporting some OS
> > with its own  boot protocol which doesn't match Linux's then that should
> > have a distinct name of its own.
> 
> zImage is the boot protocol for arm32, this is different for arm64.

They are essentially the same thing, modulo arch differences. It doesn't
seem worth defining linux-image as well as linux-zimage.

> Here
> we are talking about the protocol for dom0, why the bootloader is
> involved in it?

Ultimately the dom0 kernel is specified, by the user, in the bootloader
configuration file.

> How the interface will be exposed by grub to the user? Is it the
> "multiboot ..." line like in x86? If so, how grub will choose what is
> the boot protocol for the guest?

This is documented in the wiki. The grub syntax has defaults, but it
also supports explicit specification of the type.

> > The "ELF boot protocol" is as yet undefined. It may or may not end up
> > resembling zImage. In any case it will be a standard made up entirely by
> > us and as such xen-elf or something would be the correct name (unless it
> > happens to match zImage).
> 
> IHMO, the bootloader should only give the kernel blob to the hypervisor.
> Then it will decide what is the best protocol to use for booting dom0.

That might be nice, but is not how things are defined to work right now.

The fact is that this patch is a minor change which makes the existing
scheme less Xen specific and allows the grub implementation of multiboot
to not be to Xen specific.

If you want to make larger changes to the boot protocol then nothing
being proposed here stops you doing that in the future, we aren't
painting ourselves into any more corners than we are in without it.

Ian.


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