Re: [Qemu-devel] [PATCH v8 07/13] target-arm: Make PMCEID[01]_EL0 64 bit registers, add PMCEID[23]

[Aaron Lindsay <aaron@os.amperecomputing.com>]

On Dec 03 16:57, Richard Henderson wrote:
> On 12/3/18 4:19 PM, Peter Maydell wrote:
> > On Mon, 3 Dec 2018 at 20:45, Aaron Lindsay <aaron@os.amperecomputing.com> wrote:
> >>
> >> On Nov 30 16:10, Peter Maydell wrote:
> >>> PMCEID2 and PMCEID3 are only defined from ARMv8.1; before that they
> >>> are UNDEFINED. So these registers need to be only defined if a
> >>> suitable feature bit or ID register field check passes.
> >>
> >> It looks like we don't currently support any ARMv8.1+ CPUs and don't
> >> have an entry in the `arm_features` enum for it. I'll plan to add
> >> ARM_FEATURE_V81 and make defining these registers depend on it, assuming
> >> any future CPUs supporting it will use that, unless you feel I should do
> >> something different.
> > 
> > I think that the idea going forward is to prefer an ID
> > register check of some kind -- Richard ?
> 
> Yes.  It would appear that this feature should be controlled by
> ID_DFR0.PerfMon.  So,
> 
>   if (FIELD_EX32(cpu->id_dfr0, ID_DFR0, PERFMON) >= 4)
> 
> once the appropriate FIELDs are added to cpu.h.
> 
> Since this test is not used within translate*.c, there is no need to move
> id_dfr* into ARMISARegisters.  Since these are only aliases, they do not affect
> migration, and so do not (yet) need to be filled in by kvm.

Sounds reasonable to me. One clarification - do we also need to guard
against the 0b1111 value for ID_DFR0.PerfMon, which implies an
implementation-defined, non-PMUv3 PMU, or is it safe to assume no one
will attempt that flavor in QEMU?

-Aaron