From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37820) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aHCqy-00011B-HB for qemu-devel@nongnu.org; Thu, 07 Jan 2016 10:51:57 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aHCqu-0006tf-Fm for qemu-devel@nongnu.org; Thu, 07 Jan 2016 10:51:56 -0500 Received: from foss.arm.com ([217.140.101.70]:39446) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aHCqu-0006tU-AK for qemu-devel@nongnu.org; Thu, 07 Jan 2016 10:51:52 -0500 Date: Thu, 7 Jan 2016 15:53:19 +0000 From: Lorenzo Pieralisi Message-ID: <20160107155310.GA4064@red-moon> References: <567B41E3.5060800@roeck-us.net> 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 01:25:35PM +0000, Peter Maydell wrote: > On 24 December 2015 at 00:52, Guenter Roeck wrote: > > Hi all, > > > > since commit 60792ad349f3 ("arm64: kernel: enforce pmuserenr_el0 > > initialization > > and restore"), my arm64 qemu tests of linux-next are failing. After this > > commit, > > qemu does not display any output. > > > > Qemu version is 2.5.0. Linux kernel configuration is arm64:defconfig. > > > > qemu command line is as follows: > > > > qemu-system-aarch64 -machine virt -cpu cortex-a57 -machine type=virt > > -nographic -smp 1 \ > > -m 512 -kernel arch/arm64/boot/Image -initrd > > rootfs.arm64.cpio -no-reboot \ > > -append "console=ttyAMA0" > > > > Any idea what might cause this problem and how to fix it (presumably in > > qemu) ? > > This turns out to be because QEMU doesn't currently implement > PMUSERENR_EL0 for AArch64 (we do have an AArch32 implementation), > so you get an immediate UNDEF when the kernel touches it, followed > by an infinite loop of UNDEF exceptions because the instruction > at the UNDEF vector entrypoint is unallocated at this point in > execution. > > 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. > Since the v8 ARM ARM states that the Performance Monitors Extension is > an optional feature of an implementation, this seems like a kernel > bug to me. (QEMU should probably get round to implementing the PMU > at some point for feature parity with v7, but this has not been > a priority for us since they're not actually very useful in a > fully emulated setup.) Fixup patch coming, thanks. Lorenzo