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

[Peter Maydell]

On 12 November 2014 09:08, Claudio Fontana <address@hidden> wrote:
> As mentioned by others, I'd rather see an implementation of ACPI in QEMU which
> learns from the experience of X86 (and possibly shares some code if possible),
> rather than going in a different direction by creating device trees first,
> and then converting them to ACPI tables somewhere in the firmware, just 
> because
> device trees are "already there", for the reasons which have already been
> mentioned before by Igor and others.

I think the motivation for "leave ACPI entirely to the firmware" is not
just that the device trees are already there, but because it allows
for a cleaner separation of concerns between QEMU and the firmware
and thus makes QEMU simpler and easier to maintain in future.
However as a result of the discussion in this thread and on IRC about
what x86 QEMU/OVMF do and what the complexities of handling this in
UEFI are, I'm not as sure as I was that it's actually feasible in
practice.

I agree with you that if we have QEMU generating ACPI information
itself then we should definitely follow the existing tested approach
that x86 QEMU+OVMF have, and share code, both in QEMU and in the
UEFI firmware. (As I understand it there is a common source code
base between OVMF and the Tianocore code we're using for the ARM
QEMU UEFI firmware. I've probably got the project names wrong here;
I'm not familiar with the distinctions between Tianocore, EDK2,
OVMF, etc.)

The x86 QEMU-generating-APCI approach is more complicated than
what this RFC patchset does, since it generates various separate
tables and hands them individually to the firmware, rather than
creating a single (non-relocatable) complete ACPI blob. I would
hope we didn't need to support both "provide separated tables to
firmware" and "provide a single blob to a standalone guest kernel";
if we're agreed that ACPI should imply UEFI we can forget about
the latter, though.

thanks
-- PMM