| Message ID | 20180416140322.904-1-alex.bennee@linaro.org |
|---|---|
| State | New |
| Headers | show |
| Series | [RFC] target/arm: support reading of CNTVCT_EL0 from user-space | expand |
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
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
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
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 };
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(-) -- 2.17.0