From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60534) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XmMdT-0007Ir-LI for qemu-devel@nongnu.org; Thu, 06 Nov 2014 07:58:03 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XmMdP-0006Z0-1S for qemu-devel@nongnu.org; Thu, 06 Nov 2014 07:57:59 -0500 Received: from mx1.redhat.com ([209.132.183.28]:48298) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XmMdO-0006Yf-Po for qemu-devel@nongnu.org; Thu, 06 Nov 2014 07:57:54 -0500 Date: Thu, 6 Nov 2014 13:57:31 +0100 From: Igor Mammedov Message-ID: <20141106135731.25f0fb69@nial.usersys.redhat.com> In-Reply-To: References: <1414691045-4793-1-git-send-email-a.spyridakis@virtualopensystems.com> <20141030180216.GD31629@leverpostej> <5459F4CB.1000009@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Mark Rutland , "linaro-acpi@lists.linaro.org" , Alexander Spyridakis , Claudio Fontana , QEMU Developers , "tech@virtualopensystems.com" On Thu, 6 Nov 2014 12:44:04 +0000 Peter Maydell wrote: > On 5 November 2014 09:58, Claudio Fontana 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 >