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

[Lorenzo Pieralisi]

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