Re: [RFC PATCH] target/arm: support reading of CNTVCT_EL0 from user-space

["Alex Bennée" <alex.bennee@linaro.org>]

Peter Maydell <peter.maydell@linaro.org> writes:

> On 16 April 2018 at 15:03, Alex Bennée <alex.bennee@linaro.org> wrote:
>> Since kernel commit a86bd139f2 (arm64: arch_timer: Enable CNTVCT_EL0
>> trap..) user-space has been able to read this system register. This
>> patch enables access to that register although currently it always
>> returns 0 as we don't yet have a mechanism for managing timers in
>> linux-user mode.
>>
>> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
>> ---
>>  target/arm/helper.c | 20 +++++++++++++++++---
>>  1 file changed, 17 insertions(+), 3 deletions(-)
>>
>> diff --git a/target/arm/helper.c b/target/arm/helper.c
>> index b14fdab140..8244badd63 100644
>> --- a/target/arm/helper.c
>> +++ b/target/arm/helper.c
>> @@ -2121,11 +2121,25 @@ static const ARMCPRegInfo generic_timer_cp_reginfo[] = {
>>  };
>>
>>  #else
>> -/* In user-mode none of the generic timer registers are accessible,
>> - * and their implementation depends on QEMU_CLOCK_VIRTUAL and qdev gpio outputs,
>> - * so instead just don't register any of them.
>> +
>> +/* In user-mode most of the generic timer registers are inaccessible
>> + * however modern kernels (4.12+) allow access to cntvct_el0
>>   */
>> +
>> +static uint64_t gt_virt_cnt_read(CPUARMState *env, const ARMCPRegInfo *ri)
>> +{
>> +    /* Currently we have no support for QEMUTimer in linux-user so we
>> +     * can't call gt_get_countervalue(env).
>> +     */
>> +    return 0;
>> +}
>> +
>>  static const ARMCPRegInfo generic_timer_cp_reginfo[] = {
>> +    { .name = "CNTVCT_EL0", .state = ARM_CP_STATE_AA64,
>> +      .opc0 = 3, .opc1 = 3, .crn = 14, .crm = 0, .opc2 = 2,
>> +      .access = PL0_R, .type = ARM_CP_NO_RAW | ARM_CP_IO,
>> +      .readfn = gt_virt_cnt_read,
>> +    },
>>      REGINFO_SENTINEL
>>  };
>
> CNTVCT_EL0 isn't much use without CNTFRQ_EL0 which tells
> you how fast it ticks...

I've added it but of course:

    /* Note that CNTFRQ is purely reads-as-written for the benefit
     * of software; writing it doesn't actually change the timer frequency.
     * Our reset value matches the fixed frequency we implement the timer at.
     */

So it's not like we do anything with it internally. I assume in real
life you could mess with this but still have a monotonically increasing
counter.

>
> It looks like other targets use cpu_get_host_ticks() for an
> arbitrary time-counter thingy. Not sure you can get the frequency
> for it, though :-(

Hmm I've just used:

  return cpu_get_clock()/GTIMER_SCALE;

For now....

>
> thanks
> -- PMM


--
Alex Bennée