Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation

[Peter Maydell]

On 13 November 2014 09:57, Claudio Fontana <address@hidden> 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