From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54021) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZSXyB-0004CQ-Az for qemu-devel@nongnu.org; Thu, 20 Aug 2015 18:06:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZSXy8-0006od-00 for qemu-devel@nongnu.org; Thu, 20 Aug 2015 18:05:59 -0400 Received: from mx1.redhat.com ([209.132.183.28]:32906) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZSXni-0003PL-5J for qemu-devel@nongnu.org; Thu, 20 Aug 2015 17:55:10 -0400 Date: Thu, 20 Aug 2015 14:54:58 -0700 From: Andrew Jones Message-ID: <20150820215458.GC4174@hawk.localdomain> References: <1438860267-3401-1-git-send-email-leif.lindholm@linaro.org> <20150806122803.GA3083@hawk.localdomain> <20150806125514.GU18160@bivouac.eciton.net> <20150806132525.GC3083@hawk.localdomain> <20150820101821.GL10728@bivouac.eciton.net> <55D5B585.6070307@linaro.org> <20150820112131.GM10728@bivouac.eciton.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150820112131.GM10728@bivouac.eciton.net> Subject: Re: [Qemu-devel] [PATCH] hw/arm/virt-acpi-build: drop _ADR entry from SPCR List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Leif Lindholm Cc: Peter Maydell , Al Stone , Shannon Zhao , G Gregory , QEMU Developers On Thu, Aug 20, 2015 at 12:21:31PM +0100, Leif Lindholm wrote: > On Thu, Aug 20, 2015 at 07:09:57PM +0800, Shannon Zhao wrote: > > >>>Could somebody who understands ACPI and the ramifications > > >>>here let me know if I should apply this patch, please? > > >>>(since we're now post-2.4) > > >> > > >>I presume my opinion is clear, but I'm cc:ing some of the Linaro ACPI > > >>team. > > >> > > >>Graeme, Al - the patch in question is: > > >>https://www.mail-archive.com/qemu-devel%40nongnu.org/msg314356.html > > >> > > >Using _ADR for a non enumerable bus is undefined behaviour in the ACPI > > >specification. > > > > > >How it is used in Redhats SPCR patch is IMO wrong becuase there is no > > >guarantee that _ADR will be defined for any MMIO device in DSDT. > > > > > >I believe QEMU should not follow this just to make a non upstreamed > > >Redhat patch work. Well, it's a shame that the kernel patch that used ADR was committed to Red Hat's and Linaro's trees before it had been thought through completely, but it was. > > > > > Yeah, but when will the right kernel patch be upstreamed? Do you > > have a plan for upstreaming it? Or it's on the list already? > > It's on my way too long to-do list, but I'll need to send it out in > whatever state as an RFC this week anyway. > > > As said before, we can apply this patch after the kernel patch upstreamed. > > Meanwhile, it would be very bad if this becomes a de-facto standard, > using QEMU as a vector to (needlessly) change specifications through > the back door. If I understand correctly, then the concern is that vendors, ones which use QEMU code as their specification, will start building ACPI tables with ADR unnecessarily populated in the console uart's device table. Actually, some vendors must have already been doing that, otherwise the out-of-tree patches in RH's and Linaro's trees wouldn't have worked on bare-metal. So, what is the problem with them doing it? Just wrong because it's pointless? If I'm right about the concerns, then I don't see why we should rush this QEMU change. Also, it would be much easier to apologize to the guest kernels that the change will break, if we can point at an upstream patch that they need to backport. I.e. I still vote that we wait for the kernel patch to get upstream first. I'll also reiterate the obvious fact that the kernel can switch to CRS whenever it likes. That'll work just fine with or without QEMU taking this change. Thanks, drew