From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57569) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XoELN-00051o-L9 for qemu-devel@nongnu.org; Tue, 11 Nov 2014 11:31:07 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XoELD-0002cN-Gm for qemu-devel@nongnu.org; Tue, 11 Nov 2014 11:31:01 -0500 Received: from mail-la0-f47.google.com ([209.85.215.47]:49280) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XoELD-0002bx-7m for qemu-devel@nongnu.org; Tue, 11 Nov 2014 11:30:51 -0500 Received: by mail-la0-f47.google.com with SMTP id gd6so9601292lab.20 for ; Tue, 11 Nov 2014 08:30:48 -0800 (PST) Date: Tue, 11 Nov 2014 17:31:01 +0100 From: Christoffer Dall Message-ID: <20141111163101.GB23267@cbox> References: <1414691045-4793-1-git-send-email-a.spyridakis@virtualopensystems.com> <20141030180216.GD31629@leverpostej> <5459F4CB.1000009@huawei.com> <20141111152932.GA25295@leverpostej> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141111152932.GA25295@leverpostej> 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: Mark Rutland Cc: Peter Maydell , "linaro-acpi@lists.linaro.org" , Alexander Spyridakis , Claudio Fontana , QEMU Developers , "tech@virtualopensystems.com" On Tue, Nov 11, 2014 at 03:29:33PM +0000, Mark Rutland wrote: > Hi, > > On Thu, Nov 06, 2014 at 01:33:20PM +0000, Alexander Spyridakis wrote: > > On 6 November 2014 14:44, Peter Maydell wrote: > > > > > > > > > > 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. > > > > Hi Peter, > > > > The rational in the proposed approach is meant for cases where the > > user does not want to rely on external firmware layers. While UEFI > > could do what you are describing, the point is to avoid this not so > > trivial overhead in the booting process. Especially in the case of > > thin guests, where another software dependency is undesired. > > I'm not sure how you plan to use ACPI without UEFI, as there are several > pieces of information which ACPI misses, such as the memory map, which > must be discovered from UEFI. How do you intend to discover the memory > map without UEFI? > > Additionally, with Linux and other generic OSs, the expectation is that > the ACPI tables are discovered via the UEFI system table. How do you > intend to discover the ACPI tables? Or other system information? FWIW, Xen needs to pass the RDSP pointer along with a tiny DT containing the command line and memory information to Dom0 as well. We are currently suggesting adding an RDSP property to the chosen node in the tiny DT, but a command-line arguement like kexec proposed could be another option I guess, albeit not a very pretty one. But, what I hear from Huawei is that they don't want any DT and don't want any UEFI, so not sure how they plan on accomplishing that. -Christoffer