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?
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.
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