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