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

[Peter Maydell]

On 16 April 2018 at 16:29, Alex Bennée <address@hidden> wrote:
>
> Peter Maydell <address@hidden> 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