Re: [Qemu-devel] [PATCH v2 1/5] target-arm: Add the pmceid0 and pmceid1 registers

[Peter Maydell <peter.maydell@linaro.org>]

On 9 February 2016 at 17:48, Christopher Covington <cov@codeaurora.org> wrote:
> On 02/09/2016 12:19 PM, Peter Maydell wrote:
>> On 6 February 2016 at 00:55, Alistair Francis
>> <alistair.francis@xilinx.com> wrote:
>>> Signed-off-by: Aaron Lindsay <alindsay@codeaurora.org>
>>> Signed-off-by: Alistair Francis <alistair.francis@xilinx.com>
>>> Tested-by: Nathan Rossi <nathan@nathanrossi.com>
>>> ---
>>>
>>>  target-arm/cpu-qom.h | 2 ++
>>>  target-arm/cpu.c     | 2 ++
>>>  target-arm/cpu64.c   | 2 ++
>>>  target-arm/helper.c  | 8 ++++++++
>>>  4 files changed, 14 insertions(+)
>>>
>>> diff --git a/target-arm/cpu-qom.h b/target-arm/cpu-qom.h
>>> index 07c0a71..1cc4502 100644
>>> --- a/target-arm/cpu-qom.h
>>> +++ b/target-arm/cpu-qom.h
>>> @@ -148,6 +148,8 @@ typedef struct ARMCPU {
>>>      uint32_t id_pfr0;
>>>      uint32_t id_pfr1;
>>>      uint32_t id_dfr0;
>>> +    uint32_t pmceid0;
>>> +    uint32_t pmceid1;
>>>      uint32_t id_afr0;
>>>      uint32_t id_mmfr0;
>>>      uint32_t id_mmfr1;
>>> diff --git a/target-arm/cpu.c b/target-arm/cpu.c
>>> index 7ddbf3d..937f845 100644
>>> --- a/target-arm/cpu.c
>>> +++ b/target-arm/cpu.c
>>> @@ -1156,6 +1156,8 @@ static void cortex_a15_initfn(Object *obj)
>>>      cpu->id_pfr0 = 0x00001131;
>>>      cpu->id_pfr1 = 0x00011011;
>>>      cpu->id_dfr0 = 0x02010555;
>>> +    cpu->pmceid0 = 0x00000481; /* PMUv3 events 0x0, 0x8, and 0x11 */
>>
>> These are:
>>  SW_INCR   # insn architecturally executed, cc pass, software increment
>>  INST_RETIRED # insn architecturally executed
>>  CPU_CYCLES # cycle
>>
>> However we don't actually implement any of these, so should
>> we be advertising them?
>
> Perhaps I'm missing something, but I was under the impression that CPU
> cycle accounting was implemented as pmccntr_read/write in
> target-arm/helper.c.

Yes, but that's not the same as implementing it as an event
visible and controllable via the PM[X]EVCNTR and PM[X]EVTYPER
register interface. (The cycle count has its own set of
dedicated registers.)

> The instruction count event may need a wrapper around cpu_get_icount().
>
> SWINC is pretty trivial, but I don't think we actually use it, other
> than for some testing (but unfortunately not yet part of the
> kvm-unit-tests patchset).

Yep, so we could implement an event or two. The question is
(a) is it useful to do so? (quite possibly, though trying to get any
  kind of legitimate perf data out of a model is at best dicey)
(b) is it useful to advertise their support in this patchset but
  not actually implement the events? (much less clear)

If we want to add real events I think that should probably
be its own patchset, and for this patchset we should stick
to bringing the 64-bit PMU implementation into line with our
existing 32-bit implementation (which is a "we support no
event counters, only the separate cycle counter" implementation,
which I think is architecturally permitted: PMCR_EL0.N == 0)

Similarly in a later patch I don't think we should implement
the non-trivial PM[X]EVCNTR/PM[X]EVTYPER registers and
the selectors until we actually implement some real events
to count, ie we should postpone that to that future patchset,
not put it in this one.

thanks
-- PMM