[SeaBIOS] Moving BIOS tables from SeaBIOS to QEMU

Gerd Hoffmann kraxel at redhat.com
Thu Feb 28 12:08:02 CET 2013


On 02/28/13 10:37, David Woodhouse wrote:
> On Mon, 2013-02-25 at 15:46 +0100, Gerd Hoffmann wrote:
>>
>>> 2. Having (many!) hypervisor-specific special cases in SeaBIOS seems
>>> wildly schizophrenic without bringing any significant benefits,
>>> compared to factoring all of that out into a codebase which *already
>>> does many of the needed things*.
>>
>> It's a tradeoff.  On one hand letting coreboot handle hardware
>> initialialization would reduce the amout of code in seabios we have to
>> maintain.  On the other hand adding coreboot as middle man between qemu
>> and seabios would add some complexity to the whole mix.
> 
> But if we do it *without* coreboot, then we get to reimplement the whole
> "seabios-qemu-seabios ping-pong", as Laszlo describes it, in Tianocore
> as *well* as SeaBIOS.

A good part of that "ping pong" is for acpi table generation.  That we
don't want duplicate *that* in both tianocore and seabios is pretty
clear.  So the question is whenever we want move acpi table generation
to coreboot or to qemu?

The advantage of moving it to coreboot is that we already have some
table generation infrastructure there.

The advantage of moving it to qemu is that we can easily keep acpi
tables in sync with the virtual hardware.  We need less communication
between qemu + firmware.  We gain flexibility:  All firmware (seabios /
tianocore / coreboot) can pick up & use the tables.  That way we should
get a smooth migration path from pure seabios to coreboot+seabios (or
coreboot+tianocore+seabios), can switch firmware images for regression
testing etc.

> Using coreboot everywhere sounds good to me. Especially because on the
> Tianocore side we can push for Patrick's CorebootPkg to be the *primary*
> platform; we could even consider deprecating the qemu-specific OvmfPkg
> completely. And *that* in turn ensures that what everyone's working on
> is something that ought to be suitable for real hardware, rather than
> just qemu.

Makes sense, but is quite some way to go.

cheers,
  Gerd





More information about the SeaBIOS mailing list