From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Kiper Subject: New Xen boot infrastructure proposal Date: Tue, 21 May 2013 03:36:19 -0700 (PDT) Message-ID: <363082f7-72f9-41cc-a5b4-75ce235e6493@default> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: xen-devel@lists.xensource.com, konrad.wilk@oracle.com, stefano.stabellini@eu.citrix.com, ian.campbell@citrix.com, keir@xen.org, jbeulich@suse.com List-Id: xen-devel@lists.xenproject.org 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; } 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