On 10/8/2026 5:35 PM, Brian Cain wrote:
> {U,G,}PCYCLE now use a shared virtual-clock counter. This is closer to how
> the real PCYCLE behaves and avoids the extra work that was being done on
> every single TB.
>
> Handle SYSCFG.PCYCLEEN and the semihosting PCYCLE read.
>
> Remove the work-in-progress implementation that summed the TB instructions
> into a counter.
>
>From what I understand, PCYCLE is different from RDTSC (x86) or
CNTVCT_EL0 (aarch64) since it tracks cycles per thread, compared to
globals ticks on cpu, independently of its frequency.
Pushing a bit further, I also see that aarch64 has PMCCNTR_EL0, which
models something similar to PCYCLE.
In the case of aarch64, it's implemented based on time also, so hexagon
mimics this approach.
```
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 cpu_get_host_ticks();
#endif
}
```
So, since we are not accurate anyway, and depend on host cpu speed
through time elapsed, is there any reason to have a pcycle_freq_hz
property instead of a fixed number?
---
The rest looks good to me. It would be slightly easier to see the change
by removing the count based wip first, and then introduce the time based
implementation, but it's not a big deal.
Regards,
Pierrick
