From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45698) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XoVPe-00076h-AY for qemu-devel@nongnu.org; Wed, 12 Nov 2014 05:44:40 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XoVPY-00030K-Bm for qemu-devel@nongnu.org; Wed, 12 Nov 2014 05:44:34 -0500 Received: from mail-lb0-f169.google.com ([209.85.217.169]:62994) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XoVPY-00030D-11 for qemu-devel@nongnu.org; Wed, 12 Nov 2014 05:44:28 -0500 Received: by mail-lb0-f169.google.com with SMTP id 10so9193629lbg.0 for ; Wed, 12 Nov 2014 02:44:27 -0800 (PST) Date: Wed, 12 Nov 2014 11:44:41 +0100 From: Christoffer Dall Message-ID: <20141112104441.GF19598@cbox> References: <20141030180216.GD31629@leverpostej> <5459F4CB.1000009@huawei.com> <20141111152932.GA25295@leverpostej> <20141111163101.GB23267@cbox> <20141111164807.GC25295@leverpostej> <20141111213312.GC19598@cbox> <20141112103854.GA28015@leverpostej> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141112103854.GA28015@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 , "Ian.Campbell@citrix.com" , "linaro-acpi@lists.linaro.org" , Alexander Spyridakis , Julien Grall , Claudio Fontana , QEMU Developers , Leif Lindholm , "stefano.stabellini@citrix.com" , Grant Likely , "tech@virtualopensystems.com" , Parth Dixit On Wed, Nov 12, 2014 at 10:38:54AM +0000, Mark Rutland wrote: > On Tue, Nov 11, 2014 at 09:33:12PM +0000, Christoffer Dall wrote: > > On Tue, Nov 11, 2014 at 04:48:07PM +0000, Mark Rutland wrote: > > > 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? > > > > Plain memory nodes. There is no UEFI instance for Dom0. AFAIU x86 does > > something similar (although with some custom PV thing instead of DT), > > and when Dom0 needs UEFI runtime services, this is done through specific > > hypercalls. > > > > The Xen code is incomplete for this work, but can be followed here: > > https://git.linaro.org/people/parth.dixit/acpi-rsdp/xen.git/shortlog/refs/heads/explore-rsdp > > Thanks. > > > The Linux side is stuff based on the LEG kernel I think, not sure if > > it's pushed anywhere yet. > > > > I'm cc'ing Parth and Julien here, but I agree that having a discussion > > on this could probably be good. > > Sounds good to me. That might be worth running as a separate thread so > as not to confuse matters. Agreed. > > Perhaps just using memory nodes is fine, but so far all of the > discussions I've been in (on mailing lists and in person) regarding ACPI > have had the fundamental assumption that ACPI would require UEFI, and > the UEFI memory map is in use. Given that assumption seems to be broken > for this case, we need to revisit those discussions. > > There's also a problem in that this opens the possibility of non-Xen > !UEFI + ACPI configurations, which I don't think is something we want to > encourage. Xen is somewhat a special case because of the symbiotic > relationship with Dom0. > > > > 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. > > > > > > > I share your concern, but running another UEFI instance for Dom0 doesn't > > seem like a viable alternative either. Why is this a problem on ARM and > > not on x86 though? > > I believe that on x86 the fallback for !UEFI would be the e820 memory > map, which provides info regarding the type of the memory mapping, as > opposed to just the base + size. That said, I'm not that familiar with > e820, and from a quick look the provided information doesn't seem to be > that detailed. > right, the good old PC. > > > > 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. > > > > > > > I thought the kexec patches proposed passing the RDSP on the > > command-line to boot the secondary kernel, so if that ended up being > > supported by the kernel for kexec, maybe that could be leveraged by > > Xen's boot protocol. It was an idea someone brought to me, just thought > > I'd mention it. > > Ah, that's not something I'd heard of. Maybe there was a misunderstanding then, I thought you were cc'ed on those discussions. > > I'm not a fan of placing fundamentally required system description on > the command line. It's fine for explicit overrides but I don't think it > should be the default mechanism as that causes its own set of problems > (who wants to fight with their hypervisor to pass a command line to a > guest kernel?). > Agreed completely, but I've been lacking strong technical arguments against passing this stuff on the cmdline. My personal preferred approach for the Xen Dom0 case is to add a property to the DT. -Christoffer