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

[Gerd Hoffmann <kraxel@redhat.com>]

  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