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

[Gerd Hoffmann <kraxel@redhat.com>]

On 05/29/13 01:53, Kevin O'Connor wrote:
> 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,

I fail to see the security issues here.  It's not like the apci table
generation code operates on untrusted input from the guest ...

> complexities in running iasl on
> big-endian machines,

We already have a bunch of prebuilt blobs in the qemu repo for simliar
reasons, we can do that with iasl output too.

> possible complexity of having to regenerate
> tables on a vm reboot,

Why tables should be regenerated at reboot?  I remember hotplug being
mentioned in the call.  Hmm?  Which hotplugged component needs acpi
table updates to work properly?  And what is the point of hotplugging if
you must reboot the guest anyway to get the acpi updates needed?
Details please.

Also mentioned in the call: "architectural reasons", which I understand
as "real hardware works that way".  Correct.  But qemu's virtual
hardware is configurable in more ways than real hardware, so we have
different needs.  For example: pci slots can or can't be hotpluggable.
On real hardware this is fixed.  IIRC this is one of the reasons why we
have to patch acpi tables.

> overall sloppiness of doing it in QEMU.

/me gets the feeling that this is the *main* reason, given that the
other ones don't look very convincing to me.

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

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

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

Also simliar to the coreboot idea.

Also in the call: The idea of having some library for acpi table
generation provided by qemu which the firmware can use.  Has license
compatibility issues.  Also difficult due to the fact that there is no
libc in firmware, so such a library would need firmware-specific
abstraction layers even for simple stuff such as memory allocation.

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

Good.  I think having qemu generate the tables is also quite useful for
evaluating the move to coreboot:

  (1)  make qemu generate the acpi tables.
  (2a) make seabios use the qemu-generated tables.
  (2b) make ovmf use the qemu-generated tables.
  (2c) make coreboot use the qemu-generated tables.

Now we can look where we stand when using coreboot+seabios or
coreboot+tianocore compared to bare seabios / bare ovmf.  I expect there
are quite a few things to fix until the coreboot+seabios combo runs
without regressions compared to bare seabios.  But maybe not when qemu
provides the acpi tables to coreboot.

In case the coreboot testdrive works out well we can continue with:

  (3)  use coreboot+seabios by default.
  (4)  move acpi table generation from qemu to coreboot.

cheers,
  Gerd