From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55496) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XoWBP-0006kb-Kl for qemu-devel@nongnu.org; Wed, 12 Nov 2014 06:34:03 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XoWBI-0008MZ-3X for qemu-devel@nongnu.org; Wed, 12 Nov 2014 06:33:55 -0500 Received: from mail-la0-f48.google.com ([209.85.215.48]:41622) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XoWBH-0008MP-Sc for qemu-devel@nongnu.org; Wed, 12 Nov 2014 06:33:48 -0500 Received: by mail-la0-f48.google.com with SMTP id gq15so11026357lab.21 for ; Wed, 12 Nov 2014 03:33:46 -0800 (PST) Date: Wed, 12 Nov 2014 12:34:01 +0100 From: Christoffer Dall Message-ID: <20141112113401.GH19598@cbox> References: <1414691045-4793-1-git-send-email-a.spyridakis@virtualopensystems.com> <546323A7.6040805@huawei.com> <20141112105640.GB28015@leverpostej> <1857764.BysEu3dgOQ@wuerfel> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1857764.BysEu3dgOQ@wuerfel> 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: Arnd Bergmann Cc: Mark Rutland , Peter Maydell , Paul Mundt , linaro-acpi@lists.linaro.org, Claudio Fontana , QEMU Developers , Jani Kokkonen , "tech@virtualopensystems.com" On Wed, Nov 12, 2014 at 12:15:08PM +0100, Arnd Bergmann wrote: > On Wednesday 12 November 2014 10:56:40 Mark Rutland wrote: > > On Wed, Nov 12, 2014 at 09:08:55AM +0000, Claudio Fontana wrote: > > > On 11.11.2014 16:29, Mark Rutland wrote: > > > > > > I tend to mostly agree with this, we might look for alternative > > > solutions for speeding up guest startup in the future but in general > > > if getting ACPI in the guest for ARM64 requires also getting UEFI, > > > then I can personally live with that, especially if we strive to have > > > the kind of optimized virtualized UEFI you mention. > > > > Given that UEFI will be required for other guests (e.g. if you want to > > boot a distribution's ISO image), I hope that virtualised UEFI will see > > some optimisation work. > > I think the requirement it just for KVM to provide something that > behaves exactly like UEFI, it doesn't have to be the full Tianocore > implementation if it's easier to reimplement the boot interface. We already have a port of Tinaocode that works for virt, but yes, implementing something ligther is certainly possible. > > > > As mentioned by others, I'd rather see an implementation of ACPI in > > > QEMU which learns from the experience of X86 (and possibly shares some > > > code if possible), rather than going in a different direction by > > > creating device trees first, and then converting them to ACPI tables > > > somewhere in the firmware, just because device trees are "already > > > there", for the reasons which have already been mentioned before by > > > Igor and others. > > > > For the features which ACPI provides which device trees do not (e.g. the > > dynamic addition and removal of memory and CPUs), there will need to be > > some sort of interface between QEMU and the ACPI implementation. That's > > already outside of the realm of DT, so as previously mentioned a simple > > conversion doesn't cover the general case. > > I think we need to support the low-level interfaces in the kernel for > this anyway, we should not have to use ACPI just to do memory and CPU > hotplugging in KVM, that would be silly. I had that same intuitive feeling, but lacked good tecnical arguments for it. Care to elaborate on that? > If ACPI is present, it can > provide a wrapper for the same interface, but KVM should not need to > be aware of the fact that ACPI is used in the guest, after it has > passed the initial ACPI blob to the kernel. > That's where things begin to be a bit foggy for me. AFAIU ACPI already has a method for doing this and I speculate that there is some IRQ assigned to an ACPI event that causes some AML code to be interpreted by your OS. Wouldn't it be a matter of QEMU putting the right AML table fragments in place to wire this up then? -Christoffer