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

[Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>]

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?

Correct.

> > 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
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel