Re: [SeaBIOS] KVM call agenda for 2013-05-28

[Peter Stuge <peter@stuge.se>]

Kevin O'Connor wrote:
> one possible way forward would be to split the current SeaBIOS rom
> into two roms: "qvmloader" and "seabios".  The "qvmloader" would do
> the qemu specific platform init (pci init, smm init, mtrr init, bios
> tables) and then load and run the regular seabios rom.

qvmloader sounds a lot like coreboot.


> qvmloader could be committed into the QEMU repo and maintained there.

If QEMU really doesn't want anything besides quacking like a PC with
BIOS or UEFI (such as quacking like a PC *without* a particular
firmware) it makes perfect sense to me to put the complete firmware
code into the QEMU repo and never reuse anything else. After all,
that's how the proprietary firmware products are managed.


Jordan Justen wrote:
> Why is updating the ACPI tables in seabios viewed as such a burden?

I don't know about burden but to me it just doesn't make any sense
to generate ACPI in one component (SeaBIOS) based on configuration
for another component (QEMU).

ACPI bytes are obviously a function of QEMU configuration. QEMU
configuration can be changed through a great many channels, so it
makes sense to me that QEMU itself would take care of generating
correct ACPI, rather than exporting it's own data structures and
pushing the ACPI problem onto the firmware, especially considering
the desire for multiple independent firmware implementations.

There's some code for dynamic ACPI generation in coreboot already,
maybe that can be reused in QEMU to save some effort..


> On the flip side, why is moving the ACPI tables to QEMU such an issue?

Maybe because it is such a steaming pile that even the place where it
belongs doesn't really want it..


> I think overall I prefer the tables being built in the firmware,
> despite the extra thrash.

That doesn't make sense to me. :\

Keep in mind: there is firmware and there is firmware..


> Some things, such as the addresses where devices are configured at
> are re-programmable in QEMU, so a firmware can decide to use a
> different address, and thus invalidate the address qvmloader had
> set in the tables.

..there is now talk about a first-stage firmware (qvmloader) which
does only hardware init, and then jumps into a second-stage firmware
(SeaBIOS) which starts the operating system.

I don't expect that anyone would argue for the second-stage firmware
to generate ACPI tables if the first-stage firmware would be shared
across different second-stage implementations.

The above is by the way *exactly* the model coreboot uses since 14 years.

Please make an ernest effort to *look into and try to reuse* what *is
already there* ..

The fear of coreboot is truly amazing.


//Peter