Re: New Xen boot infrastructure proposal

[Keir Fraser <keir.xen@gmail.com>]

On 21/05/2013 11:36, "Daniel Kiper" <daniel.kiper@oracle.com> wrote:

> Hey guys,
> 
> Here are my thoughts about current Xen boot
> infrastructure and some changes proposal.
> It is linked with EFI development but not only.
> 
> Since the beginning Xen image and other needed stuff
> could be loaded into memory according to multiboot
> protocol. (e.g. implemented by GRUB). It means that
> current implementation of Xen takes info about current
> system config from multiboot_info_t structure (it is
> copied from original place in assembly files and then
> passed as an argument to __start_xen()) and some other
> BIOS sources if needed (e.g. VGA config, EDD data).
> Later when EFI come into the scene there was no significant
> change in that. multiboot_info_t structure and others
> are initialized artificially by Xen EFI boot stuff.
> Additionally, due to that there is no place for extra boot
> info in multiboot_info_t e.g. ACPI data is passed via
> supplementary global variables. Now there is a requirement
> for boot Xen on EFI platform via GRUB. Due to that new
> boot protocol called multiboot2 should be supported.
> This means that in current situation another conversion
> to legacy multiboot_info_t structure and others should be
> implemented. However, due to limitations of multiboot_info_t
> structure not all arguments (e.g. ACPI data) could be passed
> via it. That leads to further code complication. It means
> that at this stage it is worth to create completely new
> boot structure which is not linked so tightly with any boot
> protocol.

> It should contain all needed stuff, be architecture
> independent as much as possible and easily extensible.

Why and why? Well I mean we shouldn't make things deliberately architecture
*dependent*, but where tables and flags need parsing/translating I'd rather
do that once per architecture, rather than once per bootloader format (which
I am thinking are mostly arch-dependent, and hence at least as numerous as
architectures). As for easily extensible, we are talking about communication
between Xen 'pre-loaders' (we might call them) and Xen proper (eg
arch/x86/setup.c). Who cares about the hassle of extensible self-describing
formats here? Just make it a struct and extend the struct, it all gets built
together as matched sets of pre-loaders and Xen anyway.

I'd be looking for a simple extension to what we have to pass stuff like
ACPI through, if it's needed at all. Maybe clean things up a bit and work
out a nice way to mate that with the existing multiboot-centric world. I
wouldn't waste my time hitting it with the architecture sledgehammer.

 -- Keir

> In cases when architecture depended things are required
> there should be special substructure which would contain
> all required stuff. More or less it should look like in x86 case:
> 
> /* Xen Boot Info (XBI) module structure. */
> typedef struct {
>   u64 start;
>   u64 end;
>   char *cmdline;
> } xbi_mod_t;
> 
> /* Xen Boot Info Arch (XBIA) memory map structure. */
> typedef struct {
>   /*
>    * Amount of lower memory accordingly to The Multiboot
>    * Specification version 0.6.96.
>    */
>   u32 lower;
>   /*
>    * Amount of upper memory accordingly to The Multiboot
>    * Specification version 0.6.96.
>    */
>   u32 upper;
>   u32 map_size;
>   struct e820entry *e820map;
> } xbia_mem_t;
> 
> /* Xen Boot Info Arch (XBIA). */
> typedef struct {
>   EFI_SYSTEM_TABLE *efi_system_table;
>   u64 mps; /* Pointer to MPS. */
>   u64 acpi; /* Pointer to ACPI RSDP. */
>   u64 smbios; /* Pointer to SMBIOS. */
>   xbia_mem_t mem;
>   struct xen_vga_console_info vga_console_info;
>   struct edd_info *edd_info;
> } xbia_t;
> 
> /* Main Xen Boot Info (XBI) structure. */
> typedef struct {
>   char *boot_loader_name;
>   char *cmdline;
>   u32 mods_count;
>   xbi_mod_t *mods;
>   xbia_t arch;
> } xbi_t;
> 
> All data should be placed in above structures as early
> as possible. Usually it will be done in some assembly
> files before __start_xen() call or in efi_start() on EFI
> platform and in __start_xen() itself. Additionally, it
> should be mentioned that not all members are valid on
> every platform and sometimes some of them would not be
> initialized.
> 
> Daniel