[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v8 07/13] target-arm: Make PMCEID[01]_EL0 64 bit
From: |
Aaron Lindsay |
Subject: |
Re: [Qemu-devel] [PATCH v8 07/13] target-arm: Make PMCEID[01]_EL0 64 bit registers, add PMCEID[23] |
Date: |
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
> 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