On Thu, 6 Nov 2014 12:44:04 +0000 Peter Maydell peter.maydell@linaro.org wrote:
On 5 November 2014 09:58, Claudio Fontana claudio.fontana@huawei.com 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