On Fri, Feb 08, 2013 at 09:24:55AM +0000, David Woodhouse wrote:
On Fri, 2013-02-08 at 00:06 -0500, Kevin O'Connor wrote:
This patch series enables SeaBIOS to be compiled for multiple platforms (eg, CSM, QEMU, Coreboot) at the same time. This is useful for cases where SeaBIOS is running under coreboot which is running under QEMU, for example.
I think you're conflating two issues there.
Firstly, do you actually want to be able to build a multi-platform binary where a single binary build can be used *either* from Coreboot, as CSM, or directly on native hardware? Is there really a need for such a beast?
No - I don't see a need for one image to run in multiple places.
I'm not sure it would even work for CSM, because it would probably be too big.
As an aside, is there a way to pass in the "init" sections to ovmf such that they don't prevent option roms from using the space? Also, I briefly tried not padding bios.bin to a power of 2, but ovmf doesn't seem to like that.
For the case of SeaBIOS loaded via Coreboot or CSM when it's *actually* running under Qemu, all you really need to do is separate the "started on Qemu" and "running on Qemu" options.
That's kind of what this patch series attemps - distinguishing between "started on qemu" and "running on qemu".
There's really two separate goals: 1 - Don't attempt to access virtual hardware when running on real machines as that can cause very bad behavior on real hardware. 2 - Minimize the size of the bios image.
The patch series attempts to make Kconfig the sole place to control image size, and runtime the sole place to verify virtual hardware is only accessed on an emulator.
Like you point out, though, it might be simpler to add a kconfig selection to choose between qemu/csm/coreboot and then add another kconfig option to enable support for some qemu hardware when under csm or coreboot. If so, the code should still verify at runtime that it's actually running on QEMU before poking at virtual hardware - otherwise there's a risk of someone building a generic image with QEMU support, running it on real hardware, and having it cause mysterious failures due to random ports being poked.
Also, some features of QEMU wont be available when SeaBIOS is launched from CSM/coreboot, even if it is ultimately running under QEMU.
I consider that a feature. From CSM I want almost *nothing* of the Qemu support. It's supposed to be hardware-agnostic, and I don't want it to magically work on qemu and then fail on real hardware.
Good point. The patch series wouldn't have changed this though.
I only really want to be allowed to use virtio devices, and also the "real" hardware devices like lsi scsi, which are currently enabled only for QEMU for some reason (is the qemu emulation not compatible with real devices?)
Is there not a similar consideration when you're running under Coreboot?
Yes - that's why it doesn't make sense to change the Kconfig settings of the various qemu drivers from "depends on QEMU" to "depends on !COREBOOT" - the CSM is in the same situation as Coreboot. It's fine to access the hardware when under QEMU, but not when running on real hardware, and thus the driver should depend on "QEMU".
-Kevin