From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: New Xen boot infrastructure proposal Date: Thu, 23 May 2013 14:33:09 +0100 Message-ID: <1369315989.17830.66.camel@zakaz.uk.xensource.com> References: <363082f7-72f9-41cc-a5b4-75ce235e6493@default> <1369140724.21246.62.camel@zakaz.uk.xensource.com> <20130522142751.GC25607@debian70-amd64.local.net-space.pl> <1369235394.21246.179.camel@zakaz.uk.xensource.com> <1369236319.17830.1.camel@zakaz.uk.xensource.com> <20130522153426.GF25607@debian70-amd64.local.net-space.pl> <1369237291.17830.6.camel@zakaz.uk.xensource.com> <20130522161939.GH25607@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: <20130522161939.GH25607@debian70-amd64.local.net-space.pl> 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: konrad.wilk@oracle.com, xen-devel@lists.xensource.com, keir@xen.org, jbeulich@suse.com, stefano.stabellini@eu.citrix.com List-Id: xen-devel@lists.xenproject.org On Wed, 2013-05-22 at 18:19 +0200, Daniel Kiper wrote: > On Wed, May 22, 2013 at 04:41:31PM +0100, Ian Campbell wrote: > > [...] > > > In that case my question (which I think others have raised) is why does > > this need to be a complex extensible protocol at all? The two halves > > here must surely be upgraded in sync and so both sides can be changed > > whenever the data needs expanding. i.e. this is just struct boot_info, > > which perhaps contains "struct arch_boot_info arch;" > > > > Or perhaps I've just read more into what you are proposing than you were > > actually proposing. > > MBI structure which is passed to __start_xen() is strictly defined and > could not be changed. It worked very nice once but now it is not true. > It does not have enough place to pass eny extra information from other > bootloaders (in this case multiboot2 protocol aware) and there are some > members which are not used. In that case we must have e.g. global variables > or other solution to pass that extra info. That is why I think we should > build new struture which will replace MBI. "... replace Xen's internal use of MBI" would be a way of putting this which is less prone to misunderstandings, I think ;-) > It should have only data which > is used by Xen. This way we could add in the future any extra members if we > require it and we would not be so strictly bound to any boot protocol. Yes, this sounds sane. > However, I do not insist on the split between arch dependent and > independent stuff. I know this is disputable. However, I posted > that idea because I was not sure that soultion will fit. > I just wanted to dicuss pros and cons of this split too. I think you've set requirements (extensibility etc) which aren't actually required and this gave (at least me) the impression that this was something much more far reaching than it actually is. I suggest making it as simple as possible, basically a single struct, perhaps containing arch specific struct, although the single struct may actually be arch specific anyway. I'm not actually sure how useful this will be on ARM where we don't have the problem of passing stuff from real mode to protected mode (because you can only call the BIOS/bootloader routines from real mode). On ARM we already have struct dt_early_info which despite the name isn't at all specific to DT and is more than sufficient for our current needs. We will obviously just extend that as need be. I'd be happy to move that into an ARM specific place and then x86 could do its own thing too. Ian.