Re: New Xen boot infrastructure proposal

[Stefano Stabellini <stefano.stabellini@eu.citrix.com>]

On Tue, 21 May 2013, Daniel Kiper 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.
> 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;

e820map needs to be moved to an x86 specific struct.
Can we use the arch-independent memory map structs as defined in section
3.4.8 of the multiboot2 spec instead?



> } 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;

We need to add a pointer to device_tree in there.


> /* 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.

Right. We need to define an unitialized value for these fields so that
we can recognized what actually is availble.
For example on ARM both device_tree and ACPI or only one of them could
be available.