On 13 November 2014 09:57, Claudio Fontana claudio.fontana@huawei.com wrote:
I agree with you that as a result of this discussion, the solution for QEMU upstreaming purposes needs to take everything discussed (possibly more) into account.
(Picking this email as a reasonable if slightly arbitrary place to try to summarise this discussion thread...)
Everybody agrees that we need to support guests that want to use ACPI. There are several possible approaches to this that have been proposed:
1. all-in-QEMU: generate a complete single ACPI table in QEMU and pass it to the guest and/or firmware, as this RFC does
2. all-in-UEFI: don't do any ACPI table generation in QEMU; just create a device tree (and some standardised interfaces for hotplugging, etc), and let the UEFI firmware put together the ACPI tables accordingly
3. mixed-mode: follow the x86/QEMU practice, and have QEMU generate a set of ACPI table fragments, which UEFI then has to stitch together in combination with any extras it wants to add itself before passing the result to the guest. [Some of these fragments might need to be generated on-demand and supplied via a fw_cfg-like conduit device; this is necessary on x86 and might be also for ARM.]
My opinion about the best approach has swung all over the place during the course of this discussion, but at the moment I think mixed-mode is the way to go.
The most common use case for ACPI is going to be with UEFI, and I'm told that the details of Tianocore and the ACPI binary format mean that it's not possible for UEFI to edit a complete ACPI blob to add any extra items it needs to, so for this use case the all-in-QEMU approach won't work. We could in theory support all-in-QEMU as an extra boot protocol for directly booting a guest that used ACPI without UEFI, alongside one of the other two methods, but I'm pretty reluctant to support multiple ways of constructing the ACPI tables and I think we have agreement that we don't need to do that. That means we can drop 'all-in-QEMU' from consideration and concentrate on the other two options.
The all-in-UEFI approach is potentially workable, and from a QEMU maintainer's perspective it has the attraction of a clean separation: QEMU only has to describe hardware in one way, and all the ACPI related code is in the firmware. However it also has some definite demerits: * we'd need code in UEFI to create ACPI tables based on the device tree information, which is at minimum code that nobody's written yet, and could be difficult even given the restriction that it only has to cope with the particular subset of dtb that QEMU generates * adding support for something like "hotplug-$FOO" needs changes in QEMU and also in UEFI, even if UEFI would otherwise not need to care about the hotplugging, because it has to translate the relevant dtb entries into ACPI * we would need to specify and define dt bindings for any (virtual) hardware used for notifying and controlling hotplug type features rather than these being an implementation detail of QEMU (though we might want to define these anyway so that you can use hotplug etc from a non-ACPI non-UEFI guest, of course)
Going with mixed-mode does mean we end up with a sort of triplication of code (once to create the board model, once to describe it in DT and once to describe it in ACPI), but the payoff is that we get to handle ACPI the same way as we do on x86, which includes a lot of preexisting code both in QEMU and in UEFI. We also don't need to update the UEFI code when we add new hotplug features.
Does anybody have an approach that I've missed from my list of three, or any advantages/disadvantages to add that might tilt the decision in a different direction?
thanks -- PMM