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

[Anthony Liguori <anthony@codemonkey.ws>]

Kevin O'Connor <kevin@koconnor.net> writes:

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

What about a small change to the SeaBIOS build system to allow ACPI
table generation to be done via a "plugin".

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.

Then the logic is maintained stays in firmware but the churn happens in
the QEMU tree instead of the SeaBIOS tree.

Regards,

Anthony Liguori

>
> 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