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

[Igor Mammedov]

On Thu, 6 Nov 2014 12:44:04 +0000
Peter Maydell <address@hidden> wrote:

> On 5 November 2014 09:58, Claudio Fontana <address@hidden> wrote:
> > Please correct me if I am wrong, my understanding at the moment is that
> > for X86 there is an ACPI implementation in hw/acpi, with the table 
> > generation
> > happening in hw/i386/acpi-build.c .
> > Couldn't there be some unification where part of the infrastructure for
> > ACPI is reused, with arch-specific code specializing for X86 and ARM?
> > Why are ACPI tables created for X86, but cannot be created likewise for ARM?
> 
> Because then for ARM boards we'd be creating a description of the
> hardware twice, once in device tree and once in ACPI, which seems
> like unnecessary duplication.
> 
> > We need ACPI guest support in QEMU for AArch64 over here, with all features
> > (including the ability to run ACPI code and add specific tables), for
> > ACPI-based guests.
> 
> The plan for providing ACPI to guests is that we run a UEFI BIOS
> blob which is what is responsible for providing ACPI and UEFI
> runtime services to guests which need them. (The UEFI blob finds
> out about its hardware by looking at a device tree that QEMU
> passes it, but that's a detail between QEMU and its bios blob).
> This pretty much looks like what x86 QEMU used to do with ACPI
> for a very long time, so we know it's a feasible approach.
ACPI in BIOS had also led to necessity to
 1. update BIOS and QEMU in lockstep if fix/feature is must to have
 2. adding compatibility hooks so it it would work with mismatched
versions.
 3. never ending expansion of PV QEMU-BIOS interface

That's the reasons why ACPI tables are build by QEMU now, and we
probably should learn on x86 experience instead of going through
the same issues second time.

> 
> thanks
> -- PMM
>