On 10/13/2026 5:39 PM, Brian Cain wrote:
>
> 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.
>
I think it would be better yes.
>
>>
>> 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
