From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49649) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XoZCF-0006Z7-VS for qemu-devel@nongnu.org; Wed, 12 Nov 2014 09:47:06 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XoZC5-0005Rz-4W for qemu-devel@nongnu.org; Wed, 12 Nov 2014 09:46:59 -0500 Received: from mx1.redhat.com ([209.132.183.28]:53562) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XoZC4-0005Rq-So for qemu-devel@nongnu.org; Wed, 12 Nov 2014 09:46:49 -0500 Message-ID: <546372BD.1050705@redhat.com> Date: Wed, 12 Nov 2014 15:46:21 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <1414691045-4793-1-git-send-email-a.spyridakis@virtualopensystems.com> <546323A7.6040805@huawei.com> <20141112105640.GB28015@leverpostej> <1857764.BysEu3dgOQ@wuerfel> <20141112113401.GH19598@cbox> <5463490B.9080101@redhat.com> <20141112121809.GF28015@leverpostej> <54635222.5000700@redhat.com> <20141112134104.GG28015@leverpostej> <546367C2.3000603@redhat.com> <20141112141059.GH28015@leverpostej> In-Reply-To: <20141112141059.GH28015@leverpostej> Content-Type: text/plain; charset=windows-1252 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: Mark Rutland Cc: Peter Maydell , Arnd Bergmann , "linaro-acpi@lists.linaro.org" , Paul Mundt , Claudio Fontana , QEMU Developers , Jani Kokkonen , "tech@virtualopensystems.com" , Christoffer Dall On 12/11/2014 15:10, Mark Rutland wrote: >>> We can't just pick-and-mix >>> portions of ACPI and state that it's specified and standard. >> >> But that's what you already do if you want to build ACPI tables from DT. >> You are already picking-and-mixing the variable portions of the ACPI >> tables and make a DT bindings for them. > > I don't follow. I argued _against_ trying to build ACPI tables from DT > because the two don't quite match up anyway. I argued _against_ trying > to convert ACPI tables to DT in prior discussions for similar reasons. Sorry, that was not you-Mark, but more you-ARM. And in fact I'd tend to agree with you, but if there are people that want not to use ACPI or UEFI or both, I think it's better if the UEFI firmware swallows the same pill and builds ACPI from DT. > In addition to fixing up the other specs which are affected by this > (e.g. how we describe those additional CPUs). There's also some > de-ACPIing to be done in addition to de-x86ification, and we need to be > careful to ensure we have access to all the information we require in > the absence of ACPI, and that we have a well defined behaviour on both > sides of the interface for what would previously have been implicit in > ACPI. Yes, I agree. On the QEMU side the de-ACPIfication would have to be done anyway (no GPE because of the reduced hardware), but you need extra de-ACPIfication for stuff like the SRAT. > I'm not saying that this is impossible. It's just a greater body of work > than modifying one spec. No doubt about that. Paolo