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

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

On Thu, May 23, 2013 at 03:41:32PM +0300, Michael S. Tsirkin wrote:
> Juan is not available now, and Anthony asked for
> agenda to be sent early.
> So here comes:
> 
> Agenda for the meeting Tue, May 28:
> 
> - Generating acpi tables

I didn't see any meeting notes, but I thought it would be worthwhile
to summarize the call.  This is from memory so correct me if I got
anything wrong.

Anthony believes that the generation of ACPI tables is the task of the
firmware.  Reasons cited include security implications of running more
code in qemu vs the guest context, complexities in running iasl on
big-endian machines, possible complexity of having to regenerate
tables on a vm reboot, overall sloppiness of doing it in QEMU.  Raised
that QOM interface should be sufficient.

Kevin believes that the bios table code should be moved up into QEMU.
Reasons cited include the churn rate in SeaBIOS for this QEMU feature
(15-20% of all SeaBIOS commits since integrating with QEMU have been
for bios tables; 20% of SeaBIOS commits in last year), complexity of
trying to pass all the content needed to generate the tables (eg,
device details, power tree, irq routing), complexity of scheduling
changes across different repos and synchronizing their rollout,
complexity of implemeting the code in both OVMF and SeaBIOS.  Kevin
wasn't aware of a requirement to regenerate acpi tables on a vm
reboot.

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

Anthony requested that patches be made that generate the ACPI tables
in QEMU for the upcoming hotplug work, so that they could be evaluated
to see if they truly do need to live in QEMU or if the code could live
in the firmware.  There were no objections.

-Kevin