Re: [Qemu-devel] [PULL 03/12] target-arm: Add support for PMU register PMINTENSET_EL1

[Peter Maydell]

On 23 February 2017 at 13:58, Aaron Lindsay <address@hidden> wrote:
> Wei, Peter,
>
> On Feb 10 18:07, Peter Maydell wrote:
>> From: Wei Huang <address@hidden>
>>
>> This patch adds access support for PMINTENSET_EL1.
>>
>> Signed-off-by: Wei Huang <address@hidden>
>> Reviewed-by: Peter Maydell <address@hidden>
>> Message-id: address@hidden
>> Signed-off-by: Peter Maydell <address@hidden>
>> ---
>>  target/arm/cpu.h    |  2 +-
>>  target/arm/helper.c | 10 +++++++++-
>>  2 files changed, 10 insertions(+), 2 deletions(-)
>>
>> diff --git a/target/arm/cpu.h b/target/arm/cpu.h
>> index edc1f76..0956a54 100644
>> --- a/target/arm/cpu.h
>> +++ b/target/arm/cpu.h
>> @@ -309,7 +309,7 @@ typedef struct CPUARMState {
>>          uint32_t c9_pmovsr; /* perf monitor overflow status */
>>          uint32_t c9_pmuserenr; /* perf monitor user enable */
>>          uint64_t c9_pmselr; /* perf monitor counter selection register */
>> -        uint32_t c9_pminten; /* perf monitor interrupt enables */
>> +        uint64_t c9_pminten; /* perf monitor interrupt enables */
>
> PMINTENSET_EL1 and PMINTENCLR_EL1 are both 32-bit registers, just like
> their AArch32 counterparts. Is there a reason I'm missing for why this
> has been changed to a uint64_t? There are a number of other 32-bit PMU
> registers also currently being represented by uint64_t.

Two reasons:

 (1) The conceptual reason. In AArch64 "32-bit system register" is just
a convenient shorthand for "64-bit system register where the upper 32
bits are RAZ/WI". The register itself is still 64 bits and in a future
architecture revision it might end up with defined bits in the upper
half (this has happened already for a few registers).

 (2) The QEMU implementation reason. The way we implement system register
access instructions typically ends up in generating a simple "load/store
64 bit value from address" instruction. Rather than having the generic
"handle a system register access" code  have two codepaths to cope with
"64-bit sysreg that's stored in a 32-bit field" and "64-bit sysreg that's
stored in a 64-bit field", we choose to require that the fields are always
64-bits wide, so that the code that accesses them doesn't have to care.

(The implementation reason derives from the conceptual reason:
architecturally there is no real different "32-bit system register"
concept, so we don't need to implement handling differently. For
AArch32 we do distinguish between 32-bit and 64-bit coprocessor
registers, because they're really different things and need
different handling.)

thanks
-- PMM