From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Kiper Subject: Re: New Xen boot infrastructure proposal Date: Wed, 22 May 2013 16:09:48 +0200 Message-ID: <20130522140948.GA25607@debian70-amd64.local.net-space.pl> References: <363082f7-72f9-41cc-a5b4-75ce235e6493@default> <519B7EC402000078000D7B3C@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <519B7EC402000078000D7B3C@nat28.tlf.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: xen-devel , keir@xen.org, ian.campbell@citrix.com, konrad.wilk@oracle.com, stefano.stabellini@eu.citrix.com List-Id: xen-devel@lists.xenproject.org On Tue, May 21, 2013 at 01:03:48PM +0100, Jan Beulich wrote: > >>> On 21.05.13 at 12:36, Daniel Kiper wrote: > > /* 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; > > The concepts of lower, upper, and E820 memory are all very much > tied to x86. That is why this is a part of Xen Boot Info Arch (XBIA) not Xen Boot Info (XBI) which is main struct. > > /* 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; > > As are - I think - MPS, EDD, perhaps SMBIOS, and maybe VGA. As above. > If you want to design anything here (and other than you try to > suggest I don't think booting is really a process that can be made > almost arch neutral/generic), you'd need to completely separate I am aware of that and I do not insist on doing it in that way. I am just looking for best solution. > out any _potentially_ arch specific things, not just those that > today we know are specific to one arch or common between the > only two and a half we support. That may mean that _each_ of Right. > the items above should become a separate one, in which case an > enumeration concept would likely be the better one. I do not fully understand what do you mean by "enumeration concept". I think that passing info about system via many not "linked" variables is not the best idea. It works in that way today because multiboot structure is not extensible. That is why I think we should find new solution. Our new custom build structure which contains only stuff required by Xen looks good. All members are easliy accessible from C. It could be easliy extended (if we need it just add new member) because it would not be linked with specific boot protocol. However, I agree that distinction between arch dependent and independent stuff is disputable. Maybe we should drop that idea, assume that Xen Boot Info (XBI) is always arch dependent and put all needed members in one struct. IMO this is better solution than current one too. Daniel