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:43:32 +0200 Message-ID: <20130522144332.GD25607@debian70-amd64.local.net-space.pl> References: <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 In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Keir Fraser 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, May 21, 2013 at 02:24:37PM +0100, Keir Fraser wrote: > On 21/05/2013 11:36, "Daniel Kiper" wrote: [...] > > It should contain all needed stuff, be architecture > > independent as much as possible and easily extensible. > > Why and why? Well I mean we shouldn't make things deliberately architecture > *dependent*, but where tables and flags need parsing/translating I'd rather > do that once per architecture, rather than once per bootloader format (which > I am thinking are mostly arch-dependent, and hence at least as numerous as > architectures). As for easily extensible, we are talking about communication > between Xen 'pre-loaders' (we might call them) and Xen proper (eg > arch/x86/setup.c). Who cares about the hassle of extensible self-describing > formats here? Just make it a struct and extend the struct, it all gets built > together as matched sets of pre-loaders and Xen anyway. > > I'd be looking for a simple extension to what we have to pass stuff like > ACPI through, if it's needed at all. Maybe clean things up a bit and work > out a nice way to mate that with the existing multiboot-centric world. I > wouldn't waste my time hitting it with the architecture sledgehammer. I do not insist on using so complicated structure because it has some weakness which I am aware of. However, I think we should build our own structure to pass stuff from preloader (mainly assembly files) to proper Xen. It will be nice if it has place for other boot stuff collected in __start_xen() too. If we stick to old multiboot structure it will make diffculties in multiboot2 protocol implementation. For example it will be very difficult to pass (in sensible way), from preloader to Xen, info about ACPI and EFI stuff. That is why I think that this new structure should not be so tightly linked with any boot protocol. Daniel