Re: KVM call agenda for 2013-05-28

[Kevin O'Connor <kevin@koconnor.net>]

On Fri, May 31, 2013 at 07:58:36AM -0500, Anthony Liguori wrote:
> Kevin O'Connor <kevin@koconnor.net> writes:
> > 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.
> What about a small change to the SeaBIOS build system to allow ACPI
> table generation to be done via a "plugin".

Using a runtime plugin (eg, "qplugin") would require a more complex
handoff then qvmloader.  With qplugin, seabios would need to know what
memory qplugin is compiled to run in and make sure it didn't allocate
anything there.  Similarly, qplugin would need to not stomp on seabios
while it runs, and it would need to coordinate with seabios where to
place the final tables.  With qvmloader, there is no need to
coordinate memory addresses, so it can run anywhere, deploy the tables
in their final location, and then launch seabios.

> This could be as simple as moving acpi.c and *.dsl into the QEMU build
> tree and then having a way to point the SeaBIOS makefiles to our copy of
> it.

I don't see how that would work.  It would complicate the seabios
build (as it would require a copy of qemu source to compile), and the
resulting seabios binary would be strongly tied to the qemu version it
was compiled with and vice-versa.  This would break distro seabios
rpms.  It would also cause great pain when bisecting and would be
confusing even during regular compile/debug cycles.  Internal seabios
calls (eg, memory allocations, pci config accesses) would need to be
static interfaces, etc.

-Kevin