From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33510) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XoEcu-0003XX-9I for qemu-devel@nongnu.org; Tue, 11 Nov 2014 11:49:13 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XoEcp-000260-FB for qemu-devel@nongnu.org; Tue, 11 Nov 2014 11:49:08 -0500 Received: from cam-admin0.cambridge.arm.com ([217.140.96.50]:55534) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XoEcp-00025Y-5y for qemu-devel@nongnu.org; Tue, 11 Nov 2014 11:49:03 -0500 Date: Tue, 11 Nov 2014 16:48:07 +0000 From: Mark Rutland Message-ID: <20141111164807.GC25295@leverpostej> References: <1414691045-4793-1-git-send-email-a.spyridakis@virtualopensystems.com> <20141030180216.GD31629@leverpostej> <5459F4CB.1000009@huawei.com> <20141111152932.GA25295@leverpostej> <20141111163101.GB23267@cbox> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141111163101.GB23267@cbox> 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: Christoffer Dall Cc: Peter Maydell , "linaro-acpi@lists.linaro.org" , Alexander Spyridakis , Claudio Fontana , QEMU Developers , "tech@virtualopensystems.com" Hi Christoffer, On Tue, Nov 11, 2014 at 04:31:01PM +0000, Christoffer Dall wrote: > 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. When you say "memory information", is that pointers to a UEFI memory map, or memory nodes? The former should work for ACPI, but I don't think the latter will. I think there's a need for some discussion regarding the Dom0 boot flow for ACPI. Is there any tree I can take a peek at? Passing just the RDSP will mean that Dom0 won't get SMBIOS tables and other potentially useful things, in addition to simply being yet another potential boot configuration. I'm a little concerned about that. > 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. I'm not sure what an RDSP command line property would have to do with kexec. I'll assume I've misunderstood something. > 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. Indeed. Thanks, Mark.