From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: New Xen boot infrastructure proposal Date: Wed, 22 May 2013 15:33:29 +0100 Message-ID: <519CF35902000078000D8264@nat28.tlf.novell.com> References: <363082f7-72f9-41cc-a5b4-75ce235e6493@default> <519B7EC402000078000D7B3C@nat28.tlf.novell.com> <20130522140948.GA25607@debian70-amd64.local.net-space.pl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20130522140948.GA25607@debian70-amd64.local.net-space.pl> 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: Daniel Kiper 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 22.05.13 at 16:09, Daniel Kiper wrote: > 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. Okay, emphasizing this would have helped, the more that the split out xbia_mem_t suggested re-usability considerations. >> 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". That point is irrelevant with the above clarification. > 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. Why does it matter whether the MBI structure is extensible? Rather than copying everything around a number of times, we can as well use is where it lives naturally. The only requirement is that all information be accessible - whether in one strcture, two, or a dozen doesn't matter. Jan