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] [RFC] [PATCH 0/2] Basic SeaBIOS support for Xen HVM

To: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, <seabios@xxxxxxxxxxx>
Subject: [Xen-devel] [RFC] [PATCH 0/2] Basic SeaBIOS support for Xen HVM
From: Ian Campbell <Ian.Campbell@xxxxxxxxxx>
Date: Fri, 13 May 2011 16:59:03 +0100
Cc: Anthony Perard <anthony.perard@xxxxxxxxxx>
Delivery-date: Fri, 13 May 2011 09:05:20 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
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.
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
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. 

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

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.

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.

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



Xen-devel mailing list