[SeaBIOS] KVM call agenda for 2013-05-28
kraxel at redhat.com
Thu May 30 08:12:25 CEST 2013
>>> that QOM interface should be sufficient.
>> Agree on this one. Ideally the acpi table generation code should be
>> able to gather all information it needs from the qom tree, so it can be
>> a standalone C file instead of being scattered over all qemu.
> Ack. So my basic argument is why not expose the QOM interfaces to
> firmware and move the generation code there? Seems like it would be
> more or less a copy/paste once we had a proper implementation in QEMU.
Well, no. Firmware is a quite simple environment without standard libc
etc, so moving code from qemu to firmware certainly isn't as easy as
copying over a file.
>>> There were discussions on potentially introducing a middle component
>>> to generate the tables. Coreboot was raised as a possibility, and
>>> David thought it would be okay to use coreboot for both OVMF and
>> Certainly an option, but that is a long-term project.
> Out of curiousity, are there other benefits to using coreboot as a core
> firmware in QEMU?
Short-term it's alot of work as we have to bring coreboot's qemu support
to feature parity with seabios. I suspect most of this is acpi related
though, so when qemu provides the tables and coreboot uses them we could
be pretty close already.
Long-term it should simplify firmware maintainance as we have only *one*
place which handles the hardware bringup, and seabios/ovmf have less
work to do.
> Is there a payload we would ever plausibly use besides OVMF and SeaBIOS?
I wouldn't be surprised if people start using other coreboot payloads
and/or features such as direct linux kernel boot once it works well on qemu.
We might even run qemu test suites as coreboot payload.
More information about the SeaBIOS