On Oct 17 14:12, Richard Henderson wrote: > On 10/17/18 12:47 PM, Aaron Lindsay wrote: > > On Oct 16 17:04, Richard Henderson wrote: > >> On 10/10/18 1:37 PM, Aaron Lindsay wrote: > >>> + * Return the underlying cycle count for the PMU cycle counters. If > >>> we're in > >>> + * usermode, simply return 0. > >>> + */ > >>> +static uint64_t cycles_get_count(CPUARMState *env) > >>> +{ > >>> +#ifndef CONFIG_USER_ONLY > >>> + return muldiv64(qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL), > >>> + ARM_CPU_FREQ, NANOSECONDS_PER_SECOND); > >>> +#else > >>> + return 0; > >>> +#endif > >>> +} > >> > >> Usually we pass through the host cycle counter. > >> See cpu_get_host_ticks(). > > > > Why do you prefer cpu_get_host_ticks()? And are you suggesting this for > > just user-mode, or both system and user? > > Just user-mode. Providing a clock with unknown scaling is more useful than a > constant 0.
Okay, that makes sense I think. I slightly dislike the fact that the behavior is silently different between user and system mode, but perhaps some documentation could alleviate my concern - is there an appropriate place to document this difference? It occurs to me that one argument for always returning 0 is that it's immediately obvious that the behavior is different from system mode, eliminating the possibility of a user assuming results from user and system mode are comparable. -Aaron