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