[SeaBIOS] [PATCH 0/5][RFC] Simultaneous multi-platform support

[Kevin O'Connor]

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