From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50731) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aHDXT-00038I-BG for qemu-devel@nongnu.org; Thu, 07 Jan 2016 11:35:52 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aHDXQ-0003jB-1n for qemu-devel@nongnu.org; Thu, 07 Jan 2016 11:35:51 -0500 Received: from foss.arm.com ([217.140.101.70]:39665) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aHDXP-0003iV-ST for qemu-devel@nongnu.org; Thu, 07 Jan 2016 11:35:47 -0500 Date: Thu, 7 Jan 2016 16:37:22 +0000 From: Lorenzo Pieralisi Message-ID: <20160107163722.GB4064@red-moon> References: <567B41E3.5060800@roeck-us.net> <20160107155310.GA4064@red-moon> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] arm64 qemu tests failing in linux-next since 'arm64: kernel: enforce pmuserenr_el0 initialization and restore' List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Mark Rutland , Will Deacon , "linux-kernel@vger.kernel.org" , QEMU Developers , Guenter Roeck , "linux-arm-kernel@lists.infradead.org" On Thu, Jan 07, 2016 at 03:58:15PM +0000, Peter Maydell wrote: > On 7 January 2016 at 15:53, Lorenzo Pieralisi wrote: > > On Thu, Jan 07, 2016 at 01:25:35PM +0000, Peter Maydell wrote: > >> We had previously been relying on the kernel not attempting to > >> touch the PMU if the ID_AA64DFR0_EL1 PMUVer bits read 0000 > >> ("Performance Monitors extension System registers not implemented"). > > > > Ok, thanks for looking into this. I wonder why reading pmcr_el0 does > > not suffer from the same problem though. > > Just a pragmatic thing on QEMU's end, I expect -- the kernel already > touched PMCR_EL0 and we wanted to be able to boot it, so we have an > implementation of it. If that's the case, that was the wrong approach IMHO. QEMU has to comply with the Aarch64 architecture which means that either the CPU it models has a Performance Monitors extension or it does not. If reading pmcr_el0 does not fault I could tell you this is a QEMU regression because currently it _does_ model pmcr_el0 while (hopefully) ID_AA64DFR0_EL1 PMUVer reports it should not. I will add code that guards both register accesses to fix both bugs at once. Thanks, Lorenzo