On 10/13/2026 5:34 PM, Pierrick Bouvier wrote:
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
https://docs.qualcomm.com/doc/80-N2040-60/topic/registers.html#cycle-count-registers
PCYCLE is a global (per-core) cycle counter, not per-thread. The WIP
implementation accumulated counts of packets per TB during that TB
(accounting for just that thread's activity). The previous
implementation on our fork summed the counters among vCPUs on PCYCLE
register reads. This was "good enough" for a first generation but is a
less appropriate model than provided in this series and required more
work with every TB. The one nice thing was that it was stable and
consistent among hosts.
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?
---
That property was sort of an "apology" to any user who might long for
the stability of the implementation on the fork - allowing them to
calibrate as needed. I am definitely not attached to it and happy to
get rid of it.
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.
Good idea - will do.
Regards,
Pierrick
