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