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