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

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

[Alex Bennée]

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
 };
 
-- 
2.17.0

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

[Peter Maydell]

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...

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 :-(

thanks
-- PMM

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

[Alex Bennée]

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

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

[Peter Maydell]

On 16 April 2018 at 16:29, Alex Bennée <alex.bennee@linaro.org> wrote:
>
> Peter Maydell <peter.maydell@linaro.org> writes:
>> 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.

But we do correctly use it to report the frequency of our
system-mode CNTVCT counters, as the comment says.

> I assume in real
> life you could mess with this but still have a monotonically
> increasing counter.

It's purely a reporting mechanism. In real hardware the
firmware is supposed to know how fast the system clock is
and and set CNTFRQ up appropriately to tell the OS that that's
how fast the CNTVCT counter runs. (Notice that CNTFRQ is only
RW to the highest implemented exception level, and RO below that.)

>> 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....

I guess that will work -- it boils down to a gettimeofday()
syscall, which will be ok for speed if it's in a VDSO and
a bit worse if it's a real syscall.

thanks
-- PMM