From: linux@roeck-us.net (Guenter Roeck)
To: linux-arm-kernel@lists.infradead.org
Subject: [Qemu-devel] arm64 qemu tests failing in linux-next since 'arm64: kernel: enforce pmuserenr_el0 initialization and restore'
Date: Thu, 7 Jan 2016 08:21:33 -0800 [thread overview]
Message-ID: <568E908D.4070007@roeck-us.net> (raw)
In-Reply-To: <20160107155310.GA4064@red-moon>
On 01/07/2016 07:53 AM, Lorenzo Pieralisi wrote:
> On Thu, Jan 07, 2016 at 01:25:35PM +0000, Peter Maydell wrote:
>> On 24 December 2015 at 00:52, Guenter Roeck <linux@roeck-us.net> 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.
>
The following code around the register accesses fixes the problem for me.
+ mrs x0, ID_AA64DFR0_EL1
+ tst x0, #0xf00
+ b.eq 1f
msr pmuserenr_el0, xzr // Disable PMU access from EL0
+1:
I don't have a real system, so I can not verify if the register is correctly
set there. Plus, of course, I don't really know aarch64 assembler, so the above
code may be plain wrong ;-).
Guenter
WARNING: multiple messages have this Message-ID (diff)
From: Guenter Roeck <linux@roeck-us.net>
To: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
Peter Maydell <peter.maydell@linaro.org>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Will Deacon <will.deacon@arm.com>,
QEMU Developers <qemu-devel@nongnu.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Qemu-devel] arm64 qemu tests failing in linux-next since 'arm64: kernel: enforce pmuserenr_el0 initialization and restore'
Date: Thu, 7 Jan 2016 08:21:33 -0800 [thread overview]
Message-ID: <568E908D.4070007@roeck-us.net> (raw)
In-Reply-To: <20160107155310.GA4064@red-moon>
On 01/07/2016 07:53 AM, Lorenzo Pieralisi wrote:
> On Thu, Jan 07, 2016 at 01:25:35PM +0000, Peter Maydell wrote:
>> On 24 December 2015 at 00:52, Guenter Roeck <linux@roeck-us.net> 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.
>
The following code around the register accesses fixes the problem for me.
+ mrs x0, ID_AA64DFR0_EL1
+ tst x0, #0xf00
+ b.eq 1f
msr pmuserenr_el0, xzr // Disable PMU access from EL0
+1:
I don't have a real system, so I can not verify if the register is correctly
set there. Plus, of course, I don't really know aarch64 assembler, so the above
code may be plain wrong ;-).
Guenter
WARNING: multiple messages have this Message-ID (diff)
From: Guenter Roeck <linux@roeck-us.net>
To: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
Peter Maydell <peter.maydell@linaro.org>
Cc: Mark Rutland <mark.rutland@arm.com>,
Will Deacon <will.deacon@arm.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
QEMU Developers <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] arm64 qemu tests failing in linux-next since 'arm64: kernel: enforce pmuserenr_el0 initialization and restore'
Date: Thu, 7 Jan 2016 08:21:33 -0800 [thread overview]
Message-ID: <568E908D.4070007@roeck-us.net> (raw)
In-Reply-To: <20160107155310.GA4064@red-moon>
On 01/07/2016 07:53 AM, Lorenzo Pieralisi wrote:
> On Thu, Jan 07, 2016 at 01:25:35PM +0000, Peter Maydell wrote:
>> On 24 December 2015 at 00:52, Guenter Roeck <linux@roeck-us.net> 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.
>
The following code around the register accesses fixes the problem for me.
+ mrs x0, ID_AA64DFR0_EL1
+ tst x0, #0xf00
+ b.eq 1f
msr pmuserenr_el0, xzr // Disable PMU access from EL0
+1:
I don't have a real system, so I can not verify if the register is correctly
set there. Plus, of course, I don't really know aarch64 assembler, so the above
code may be plain wrong ;-).
Guenter
next prev parent reply other threads:[~2016-01-07 16:21 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-24 0:52 arm64 qemu tests failing in linux-next since 'arm64: kernel: enforce pmuserenr_el0 initialization and restore' Guenter Roeck
2015-12-24 0:52 ` [Qemu-devel] " Guenter Roeck
2015-12-24 0:52 ` Guenter Roeck
2016-01-06 11:21 ` Lorenzo Pieralisi
2016-01-06 11:21 ` [Qemu-devel] " Lorenzo Pieralisi
2016-01-06 11:21 ` Lorenzo Pieralisi
2016-01-07 13:25 ` [Qemu-devel] " Peter Maydell
2016-01-07 13:25 ` Peter Maydell
2016-01-07 13:25 ` Peter Maydell
2016-01-07 15:53 ` Lorenzo Pieralisi
2016-01-07 15:53 ` Lorenzo Pieralisi
2016-01-07 15:53 ` Lorenzo Pieralisi
2016-01-07 15:58 ` Peter Maydell
2016-01-07 15:58 ` Peter Maydell
2016-01-07 15:58 ` Peter Maydell
2016-01-07 16:37 ` Lorenzo Pieralisi
2016-01-07 16:37 ` Lorenzo Pieralisi
2016-01-07 16:37 ` Lorenzo Pieralisi
2016-01-07 16:56 ` Peter Maydell
2016-01-07 16:56 ` Peter Maydell
2016-01-07 16:56 ` Peter Maydell
2016-01-07 17:13 ` Guenter Roeck
2016-01-07 17:13 ` Guenter Roeck
2016-01-07 17:13 ` Guenter Roeck
2016-01-07 17:10 ` Guenter Roeck
2016-01-07 17:10 ` Guenter Roeck
2016-01-07 17:10 ` Guenter Roeck
2016-01-07 17:19 ` Peter Maydell
2016-01-07 17:19 ` Peter Maydell
2016-01-07 17:19 ` Peter Maydell
2016-01-07 18:31 ` Lorenzo Pieralisi
2016-01-07 18:31 ` Lorenzo Pieralisi
2016-01-07 18:31 ` Lorenzo Pieralisi
2016-01-07 16:21 ` Guenter Roeck [this message]
2016-01-07 16:21 ` Guenter Roeck
2016-01-07 16:21 ` Guenter Roeck
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=568E908D.4070007@roeck-us.net \
--to=linux@roeck-us.net \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.