Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1303585 > unrolled thread

Re: [Qemu-devel] arm64 qemu tests failing in linux-next since 'arm64: kernel: enforce pmuserenr_el0 initialization and restore'

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [Qemu-devel] arm64 qemu tests failing in linux-next since 'arm64:  kernel: enforce pmuserenr_el0 initialization and restore' Peter Maydell <peter.maydell@linaro.org> - 2016-01-07 14:30 +0100
    Re: [Qemu-devel] arm64 qemu tests failing in linux-next since  'arm64: kernel: enforce pmuserenr_el0 initialization and restore' Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> - 2016-01-07 17:00 +0100
      Re: [Qemu-devel] arm64 qemu tests failing in linux-next since 'arm64:  kernel: enforce pmuserenr_el0 initialization and restore' Peter Maydell <peter.maydell@linaro.org> - 2016-01-07 17:00 +0100
        Re: [Qemu-devel] arm64 qemu tests failing in linux-next since  'arm64: kernel: enforce pmuserenr_el0 initialization and restore' Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> - 2016-01-07 17:40 +0100
          Re: [Qemu-devel] arm64 qemu tests failing in linux-next since 'arm64:  kernel: enforce pmuserenr_el0 initialization and restore' Peter Maydell <peter.maydell@linaro.org> - 2016-01-07 18:00 +0100
            Re: [Qemu-devel] arm64 qemu tests failing in linux-next since 'arm64:  kernel: enforce pmuserenr_el0 initialization and restore' Guenter Roeck <linux@roeck-us.net> - 2016-01-07 18:20 +0100
          Re: [Qemu-devel] arm64 qemu tests failing in linux-next since 'arm64:  kernel: enforce pmuserenr_el0 initialization and restore' Guenter Roeck <linux@roeck-us.net> - 2016-01-07 18:20 +0100
            Re: [Qemu-devel] arm64 qemu tests failing in linux-next since 'arm64:  kernel: enforce pmuserenr_el0 initialization and restore' Peter Maydell <peter.maydell@linaro.org> - 2016-01-07 18:30 +0100
            Re: [Qemu-devel] arm64 qemu tests failing in linux-next since  'arm64: kernel: enforce pmuserenr_el0 initialization and restore' Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> - 2016-01-07 19:40 +0100
      Re: [Qemu-devel] arm64 qemu tests failing in linux-next since 'arm64:  kernel: enforce pmuserenr_el0 initialization and restore' Guenter Roeck <linux@roeck-us.net> - 2016-01-07 17:30 +0100

#1303585 — Re: [Qemu-devel] arm64 qemu tests failing in linux-next since 'arm64: kernel: enforce pmuserenr_el0 initialization and restore'

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").

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.)

thanks
-- PMM
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1303695 — Re: [Qemu-devel] arm64 qemu tests failing in linux-next since 'arm64: kernel: enforce pmuserenr_el0 initialization and restore'

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.

Lorenzo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1303704

On 7 January 2016 at 15:53, Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> 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.

thanks
-- PMM
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1303729 — Re: [Qemu-devel] arm64 qemu tests failing in linux-next since 'arm64: kernel: enforce pmuserenr_el0 initialization and restore'

On Thu, Jan 07, 2016 at 03:58:15PM +0000, Peter Maydell wrote:
> On 7 January 2016 at 15:53, Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1303736

On 7 January 2016 at 16:37, Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> wrote:
> On Thu, Jan 07, 2016 at 03:58:15PM +0000, Peter Maydell wrote:
>> On 7 January 2016 at 15:53, Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> 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 :-)

thanks
-- PMM
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1303742

On 01/07/2016 08:56 AM, Peter Maydell wrote:
> On 7 January 2016 at 16:37, Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> wrote:
>> On Thu, Jan 07, 2016 at 03:58:15PM +0000, Peter Maydell wrote:
>>> On 7 January 2016 at 15:53, Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> 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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1303741

On 01/07/2016 08:37 AM, 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 <lorenzo.pieralisi@arm.com> 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.
>

Strictly speaking you may be right (regression is a bit strong, though),
but for my part I tend to be pragmatic.

A warning message such as "Access to unimplemented register X" may be useful,
but effectively disabling all (older) aarch64 Linux kernels in qemu could be
seen as a bit dogmatic and would not be very helpful.

> I will add code that guards both register accesses to fix both bugs at
> once.
>

I assume you'll fix the the unconditional access(es) to pmcr_el0.

Question here is the scope of registers associated with PMUVer. Are there
any other registers which would need to be guarded ?

Thanks,
Guenter

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1303753

On 7 January 2016 at 17:10, Guenter Roeck <linux@roeck-us.net> wrote:
> Strictly speaking you may be right (regression is a bit strong, though),
> but for my part I tend to be pragmatic.
>
> A warning message such as "Access to unimplemented register X" may be
> useful

You can get these from QEMU if you pass it "-d unimp", which logs
various kinds of things-not-yet-implemented, with a couple of caveats:
 * the warning is when we translate the code, not when we execute it
 * it won't warn for registers which we implement but not completely
   (eg only partial functionality or dummy reads-as-written)

In this case it printed
"write access to unsupported AArch64 system register op0:3 op1:3 crn:9
crm:14 op2:0"

The 'guest_errors' suboption to -d warns about things which appear
to be errors in the guest OS, for instance some kinds of UNPREDICTABLE,
and may also be of interest.

Neither guest_errors nor unimp are comprehensive (there are many
more situations where we don't warn than where we do) but they can
be helpful sometimes.

thanks
-- PMM
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1303799 — Re: [Qemu-devel] arm64 qemu tests failing in linux-next since 'arm64: kernel: enforce pmuserenr_el0 initialization and restore'

On Thu, Jan 07, 2016 at 09:10:14AM -0800, Guenter Roeck wrote:

[...]

> >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.
> >
> 
> Strictly speaking you may be right (regression is a bit strong, though),
> but for my part I tend to be pragmatic.

It is a kernel bug and I will fix it. Regardless, I still think that
modelling pmcr_el0 to make sure the kernel boot even with ID_AA64DFR0_EL1
PMUVer reporting that the CPU is not implementing a Performance Monitors
extension was wrong.

> A warning message such as "Access to unimplemented register X" may be useful,
> but effectively disabling all (older) aarch64 Linux kernels in qemu could be
> seen as a bit dogmatic and would not be very helpful.
> 
> >I will add code that guards both register accesses to fix both bugs at
> >once.
> >
> 
> I assume you'll fix the the unconditional access(es) to pmcr_el0.

Yes.

> Question here is the scope of registers associated with PMUVer. Are there
> any other registers which would need to be guarded ?

None that I am aware of, other PMU registers are accessed only if PMUs
are probed (since they are present in DT or ACPI), which means that at
that point QEMU will have to model the Performance Monitors extension
entirely since it advertises them in the respective FW.

I could add a warning in the v8 PMU probing path to check PMUVer if we
think that's helpful.

Lorenzo

[toc] | [prev] | [next] | [standalone]

#1303726

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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web