From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: New Xen boot infrastructure proposal Date: Wed, 22 May 2013 17:56:15 +0100 Message-ID: References: <20130522164745.GD9712@phenom.dumpdata.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20130522164745.GD9712@phenom.dumpdata.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: Konrad Rzeszutek Wilk , Jan Beulich Cc: Daniel Kiper , stefano.stabellini@eu.citrix.com, keir@xen.org, ian.campbell@citrix.com, xen-devel List-Id: xen-devel@lists.xenproject.org On 22/05/2013 17:47, "Konrad Rzeszutek Wilk" wrote: > On Wed, May 22, 2013 at 04:16:30PM +0100, Jan Beulich wrote: >>>>> On 22.05.13 at 17:01, Daniel Kiper wrote: >>> If we stick to current MBI I am not able to pass (in sensible way), >>> from preloader to __start_xen(), e.g. ACPI and EFI stuff from multiboot2 >>> protocol. >> >> Why? You get handed a list (almost like an array) of items, and you'd >> pass the base address instead of the base address of the multiboot >> structure that we pass right now, together with an indicator which >> of the two it is. Then __start_xen() has to adopt its behavior to this. >> Not a big deal afaict. > > Won't you have to do a bunch of 'if (multibootv1) { use_this_offset } else > if (multibootv2) { use this other offset }' in the code to support > both formats? > > If we just have a mesh of both of them we only have to do this sort > of copying only once and can just use the struct that encompasses > v2, v1, and whatever else we need (say pointer to RSDT). Yes, having all the x86 (say) preloaders marshal into one single x86-specific format makes sense. That's the sort of patch I would support. -- Keir > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel