[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-arm] [PATCH v8 07/13] target-arm: Make PMCEID_EL0 64 bit r
Re: [Qemu-arm] [PATCH v8 07/13] target-arm: Make PMCEID_EL0 64 bit registers, add PMCEID
Wed, 5 Dec 2018 13:00:52 +0000
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 <address@hidden> 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
> 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?