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

[Kevin O'Connor]

On Tue, May 28, 2013 at 07:53:09PM -0400, Kevin O'Connor wrote:
> 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.  The possibility was also raised of a "rom" that lives in the
> qemu repo, is run in the guest, and generates the tables (which is
> similar to the hvmloader approach that Xen uses).

Given the objections to implementing ACPI directly in QEMU, 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.  With this
split, qvmloader could be committed into the QEMU repo and maintained
there.  This would be analogous to Xen's hvmloader with the seabios
code used as a starting point to implement it.

With both the hardware implementation and acpi descriptions for that
hardware in the same source code repository, it would be possible to
implement changes to both in a single patch series.  The fwcfg entries
used to pass data between qemu and qvmloader could also be changed in
a single patch and thus those fwcfg entries would not need to be
considered a stable interface.  The qvmloader code also wouldn't need
the 16bit handlers that seabios requires and thus wouldn't need the
full complexity of the seabios build.  Finally, it's possible that
both ovmf and seabios could use a single qvmloader implementation.

On the down side, reboots can be a bit goofy today in kvm, and that
would need to be settled before something like qvmloader could be
implemented.  Also, it may be problematic to support passing of bios
tables from qvmloader to seabios for guests with only 1 meg of ram.

Thoughts?
-Kevin