[+Mostafa]
On Thu, Aug 21, 2025 at 09:14:04AM +0100, Vincent Donnefort wrote:
> By default, the arm64 host kernel is using the arch timer as a source
> for sched_clock. Conveniently, EL2 has access to that same counter,
> allowing to generate clock values that are synchronized.
>
> The clock needs nonetheless to be setup with the same slope values as
> the kernel. Introducing at the same time trace_clock() which is expected
> to be later configured by the hypervisor tracing.
>
> Signed-off-by: Vincent Donnefort <[email protected]>
[...]
> +/* Using host provided data. Do not use for anything else than debugging. */
> +u64 trace_clock(void)
> +{
> + struct clock_data *clock = &trace_clock_data;
> + u64 bank = smp_load_acquire(&clock->cur);
> + u64 cyc, ns;
> +
> + cyc = __arch_counter_get_cntpct() - clock->data[bank].epoch_cyc;
> +
> + if (likely(cyc < clock->data[bank].cyc_overflow64)) {
> + ns = cyc * clock->data[bank].mult;
> + ns >>= clock->data[bank].shift;
> + } else {
> + ns = __clock_mult_uint128(cyc, clock->data[bank].mult,
> + clock->data[bank].shift);
> + }
> +
> + return (u64)ns + clock->data[bank].epoch_ns;
So the comment here say this is for debugging only but, afaict, this
would also be useful for the cmdq timeouts in your nested SMMU series [1]
and would remove the need to mess around with the clock frequency in
the driver code...
Will
[1] https://lore.kernel.org/lkml/[email protected]/
