Re: [Xen-devel] [PATCH RFC 4/7] xen/x86: Migrate to XBI structure

[Daniel Kiper <daniel.kiper@xxxxxxxxxx>]

On Fri, Aug 08, 2014 at 05:07:09PM -0700, Roy Franz wrote:
> On Fri, Aug 8, 2014 at 4:04 PM, Daniel Kiper <daniel.kiper@xxxxxxxxxx> wrote:
> > We have all constants and structures in place. So, finally break multiboot 
> > (v1)
> > protocol dependency. It means that most of Xen code (excluding preloader)
> > could be bootloader agnostic and does not need almost any knowledge about
> > boot protocol. Additionally, we are able to pass all boot data to 
> > __start_xen()
> > in one bucket without any side channels. I do not mention that we are also
> > able to easily identify boot data in Xen code.
> >
> > Here is boot data flow for legacy BIOS platform:
> >
> >   BIOS -> GRUB -> multiboot[12]* -> __reloc() -> MBD ->-\
> >                                                         /
> >                      -----------------<-----------------
> >                      \
> >                       \
> >                        ---> __init_xbi() -> XBI_MB -> __start_xen() -> XBI
> >                       /
> >              BIOS ->-/
> >
> >   * multiboot2 is not implemented yet. Look for it in next patch.
> >
> > Here is boot data flow for EFI platform:
> >
> >   EFI -> efi_start() -> XBI_EFI -> __start_xen() -> XBI
> >
> > WARNING: ARM build could be broken by this patch. We need to agree XBI
> > integration into ARM. Personally I think that it is worth storing all
> > data from any bootloader and preloader in XBI on any architecture. This
> > give a chance to share more code between architectures. However, every
> > architecture should define its own XBI (in relevant include/asm directory).
> > Despite that it looks that some parts of it could be common, e.g.  modules
> > data, command line arguments, boot loader name, EFI data, etc., even if 
> > types
> > would not be the same. So, as it was stated above a lot of code could be
> > shared among architectures.
>
> From looking at this patch, it only conflicts slightly with the arm64 EFI work
> I have been doing.  Most of the changes are to areas of efi/boot.c that I 
> don't
> touch.  From a practical point of view it should be relatively easy
> for me to base
> my patch series on yours or vice versa.

That is great! However, does it mean that we are able to share EFI runtime
related parts between ARM and x86 only? Is it not possible to do that
in regards to EFI boot related stuff? What is different?

> GRUB uses device tree to describe modules passed to XEN, so it's
> not clear to me what the advantage of translating a device tree description
> of modules into an ARM specific XBI structure would have.

I suppose that thanks to XBI we would be able to avoid patches like
commit 55862a9383fdefa41db8790d5e1379dffc97387d (xen/xsm: Don't use
multiboot by default to initialize XSM). This is one example. There are
more places where common Xen code touches multiboot variable (mbi) too.
This makes code sharing among architectures more difficult because you must
add #ifdef stuff in theoretically common files which is not nice. So, I
think that there are some gains which we could get from introducing XBI
as a common boot data holder.

Side note: I do not know ARM a lot so please correct me if I am wrong.

Daniel

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