From mboxrd@z Thu Jan  1 00:00:00 1970
From: "Jan Beulich" <JBeulich@suse.com>
Subject: Re: New Xen boot infrastructure proposal
Date: Thu, 23 May 2013 07:37:58 +0100
Message-ID: <519DD56602000078000D857D@nat28.tlf.novell.com>
References: <363082f7-72f9-41cc-a5b4-75ce235e6493@default>
	<519B7EC402000078000D7B3C@nat28.tlf.novell.com>
	<20130522140948.GA25607@debian70-amd64.local.net-space.pl>
	<519CF35902000078000D8264@nat28.tlf.novell.com>
	<20130522150104.GE25607@debian70-amd64.local.net-space.pl>
	<519CFD6E02000078000D82BF@nat28.tlf.novell.com>
	<20130522164745.GD9712@phenom.dumpdata.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <20130522164745.GD9712@phenom.dumpdata.com>
Content-Disposition: inline
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Daniel Kiper <daniel.kiper@oracle.com>, xen-devel <xen-devel@lists.xen.org>, keir@xen.org, ian.campbell@citrix.com, stefano.stabellini@eu.citrix.com
List-Id: xen-devel@lists.xenproject.org

>>> On 22.05.13 at 18:47, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> On Wed, May 22, 2013 at 04:16:30PM +0100, Jan Beulich wrote:
>> >>> On 22.05.13 at 17:01, Daniel Kiper <daniel.kiper@oracle.com> 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?

Yes, if this became unwieldy, I would favor the single copy approach.
Or the alternative of having the initial parts of __start_xen() split off
into two clones or prefixed by additional C code (i.e. basically the
approach the current EFI boot code is using).

Jan