From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33342) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aHE7t-0003VU-HM for qemu-devel@nongnu.org; Thu, 07 Jan 2016 12:13:30 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aHE7p-0007k2-AH for qemu-devel@nongnu.org; Thu, 07 Jan 2016 12:13:29 -0500 Received: from bh-25.webhostbox.net ([208.91.199.152]:44752) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aHE7p-0007jx-57 for qemu-devel@nongnu.org; Thu, 07 Jan 2016 12:13:25 -0500 References: <567B41E3.5060800@roeck-us.net> <20160107155310.GA4064@red-moon> <20160107163722.GB4064@red-moon> From: Guenter Roeck Message-ID: <568E9CB2.60301@roeck-us.net> Date: Thu, 7 Jan 2016 09:13:22 -0800 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit 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 , Lorenzo Pieralisi Cc: Mark Rutland , Will Deacon , "linux-kernel@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , QEMU Developers On 01/07/2016 08:56 AM, Peter Maydell wrote: > On 7 January 2016 at 16:37, Lorenzo Pieralisi wrote: >> On Thu, Jan 07, 2016 at 03:58:15PM +0000, Peter Maydell wrote: >>> On 7 January 2016 at 15:53, Lorenzo Pieralisi wrote: >>>> 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 agree it's a bug, but QEMU simply doesn't have enough > developers to become fully compliant with the architecture (ie to > implement every part of it completely). So we concentrate on the > parts that people are actually using, and fill in the rest and > fix the bugs as time permits or as real guest software starts to > use it. > > If you want a guaranteed matches-the-architecture software model > of an ARM CPU then other models are available :-) > I think it would be better to convince ARM to put some manpower into enhancing qemu, instead of telling them to use some other model ;-). Guenter