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

Gerd Hoffmann kraxel at redhat.com
Thu May 30 08:12:25 CEST 2013


  Hi,

>>> Raised
>>> 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
>>> SeaBIOS.
>>
>> 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.

cheers,
  Gerd





More information about the SeaBIOS mailing list