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