This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


[Xen-devel] Re: [SeaBIOS] [RFC] [PATCH 0/2] Basic SeaBIOS support for Xe

To: Kevin O'Connor <kevin@xxxxxxxxxxxx>
Subject: [Xen-devel] Re: [SeaBIOS] [RFC] [PATCH 0/2] Basic SeaBIOS support for Xen HVM
From: Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>
Date: Mon, 16 May 2011 09:44:28 +0100
Cc: Anthony Perard <anthony.perard@xxxxxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, "seabios@xxxxxxxxxxx" <seabios@xxxxxxxxxxx>
Delivery-date: Mon, 16 May 2011 01:45:07 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20110514133622.GB7008@xxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Organization: Citrix Systems, Inc.
References: <1305302343.31488.162.camel@xxxxxxxxxxxxxxxxxxxxxx> <20110514133622.GB7008@xxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Sat, 2011-05-14 at 14:36 +0100, Kevin O'Connor wrote:
> On Fri, May 13, 2011 at 04:59:03PM +0100, Ian Campbell wrote:
> > As you may know we (the Xen project) are hoping to transition to SeaBIOS
> > at the same time as we transition to the recently upstreamed qemu
> > support for Xen.
> > 
> > The following patches add very basic support for running SeaBIOS as the
> > BIOS for a Xen HVM (fully virtualised) guest. 
> Just so I understand, is this needed for Xen pre-qemu integration,
> post-qemu integration, or both?

We'd like to have all the pieces in place for the Xen 4.2 release, which
isn't really planned out yet, but I think the late end of this year
would be a reasonable bet. I think we can be flexible around the order
integration happens in, we simply won't flip the default until
everything is in place.

Is that what you meant by post/pre-qemu integration?

> These patches really do very little but they are sufficient to allow me
> > to boot an HVM Linux guest to a prompt. SeaBIOS boots indirectly as an
> > hvmloader payload with the first patch and directly if using the second
> > (this second case requires a short patch series on the Xen side, see
> > [0]).
> So, patch 1 in this thread is needed for indirect, and patch 1+2 in
> this thread is needed for direct?


> > This is presented more as a proof of concept since it's not obvious yet
> > which approach will be best from either Xen or SeaBIOS's point of view.
> > 
> > I'm generally leaning towards the second option since much of the setup
> > currently done in hvmloader appears to be more down to the limitations
> > of ROMBIOS than any particular design decision. For example SeaBIOS is
> > perfectly happy loading option ROMS from the appropriate BAR so that
> > aspect of hvmloader goes away entirely, similarly with building ACPI,
> > SMBIOS, MP tables etc. I'd be glad to hear any opinions from either side
> > on the matter.
> I'm okay with the second option.  This is reminiscent of the
> seabios+coreboot integration - there used to be an assembler loader
> (called ADLO) that would do all sorts of weird things to get rombios
> to load.  One of my goals with SeaBIOS was to make that unnecessary.
> > One problem I have with the first patch is that I'm lacking the
> > vocabulary to describe the configuration which is currently represented
> > by COREBOOT=n. I wanted to switch the coreboot option to a Kconfig
> > choice (so I can add XEN as another option) so I needed a name for the
> > other option. I went with GENERIC but I've no idea if that is accurate.
> > Is "EMULATOR" more accurate? Suggestions welcome.
> The preferred approach would be to autodetect Xen at runtime and use
> that to control the code flow.  A CONFIG_XEN option would then only be
> used to reduce the overall code size for those that do not need Xen
> support and want a smaller binary.

Sure. I'll change things to do it that way then.

As well as CONFIG_XEN should I be adding a xen_present variable which is
set dynamically and used as appropriate? If so then is a #ifdef to
define it to 0 in the !CONFIG_XEN case (to allow the dead code to be
eliminated) necessary? Or is gcc's whole program optimisation smart
enough to spot when a global variable is never set != 0 and eliminate
code as necessary?

> Admittedly, CONFIG_COREBOOT doesn't do this today, but that's only
> because I haven't gotten around to fixing it.  (Ideally, there'd be
> something like a CONFIG_EMULATORS (for qemu/kvm/bochs) and a
> CONFIG_COREBOOT, and everything would be auto-detected if both were
> enabled at the same time.
> > FWIW I expect (however naive it might be to make such predictions) the
> > majority of the work to integrate SeaBIOS into Xen (other than test,
> > test and more test with different OSes) will be to understand he
> > differences in the various BIOS tables and figure out what is "just
> > because", what represents real bug fixes on one side or the other, what
> > is actually down to implementation details in Xen and what is down to
> > differences between the old qemu-xen and upstream qemu. Having worked
> > through all that I hope that actually finding a clean way to integrate
> > the differences with SeaBIOS (or possibly qemu) will be comparatively
> > trivial...
> Sounds good.
> -Kevin

Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>