Re: [Xen-devel] [PATCH for-xen-4.5 v4 00/18] xen: Break multiboot (v1) dependency and add multiboot2 support

[Daniel Kiper <daniel.kiper@xxxxxxxxxx>]

On Thu, Oct 23, 2014 at 04:26:22PM +0100, Jan Beulich wrote:
> >>> On 23.10.14 at 16:57, <daniel.kiper@xxxxxxxxxx> wrote:
> > multiboot1 and multiboot2 are completely different things. If we do what
> > you suggest then at least we will be forced to complicate assembly code
> > parsing cmdline in xen/arch/x86/boot/cmdline.S. We could also stay with
> > multiboot1 stuff but then we will be forced to put all stuff which we are
> > able to put in multiboot1. However, we are not able to put at least
> > EFI_HANDLE
> > and EFI_SYSTEM_TABLE from multiboot2 (which are a must on EFI; maybe we
> > want other data from multiboot2 protocol too) in multiboot1 struct because
> > there is not designed place for that. It means that we must add another
> > global variables which will appear from nowhere in Xen code (as usual
> > in case of global variables).
>
> There's nothing wrong with adding global variables, even less so
> when they're __initdata.
>
> > I understand that gains are not clearly visible at this stage of development
> > because there is lack of relevant multiboot2 + EFI code on top of this
> > patches.
> > However, I hope that above explanation and earlier ones will clear some
> > of your doubts.
> >
> > Guys, if you wish I can do what Jan suggest. However, personally I think
> > that it will complicate things more which are already complicated enough.
> > I can understand that Xen was tied to multiboot1 protocol at early stage of
> > development. Even I am able to understand that this thing was not changed
> > during introduction of EFI code. However, I think that right know, when we
> > introduce third boot protocol, mutliboot2, there is not longer any excuse to
> > have it build in early and in main Xen code especially. So, IMO we should
> > do all cleanups and fixes first and then put all multiboot2 + EFI stuff
> > on top of it. If we reverse the order then I do not believe that cleanup
> > will be done in foreseeable future.
>
> Repeating the same arguments over and over won't make them any
> better. And if MB1, MB2, and EFI are (reasonably) separate rather than
> all intermixed, maybe that's going to be the more maintainable state in
> the end anyway? We just can't tell without the MB2 pieces (separately)
> in place yet.

OK, AIUI you suggest that I should parse all multiboot2 data in reloc.c
and put all things in multiboot1 struct which lives on trampoline. Then
I should add global variables for EFI_HANDLE and EFI_SYSTEM_TABLE somewhere
in x86_64.S and initialize them from reloc.c. After that I should call
efi_start() immediately after reloc() if Xen runs on EFI platform.
Am I right?

Daniel

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