Re: [PATCH] sched_clock: Add option to use absolute time against hardware clock reset

[Feng Tang]

On Thu, Sep 03, 2026 at 08:38:57AM +0100, Marc Zyngier wrote:
[...]
> > Hi Marc,
> > 
> > > The other thing is that your "absolute" clock isn't absolute at
> > > all. This doesn't consider SW running at EL2 that could happily offset
> > > thing by an arbitrary value.
> > 
> > Do you mean the VM case that VM's vcounter can be changed by hypervisor
> > in EL2, Thus it's not that absolute in such scenario ?
> 
> That's indeed one of the possibilities. EL2 controls both virtual and
> physical offsets, and therefore provides the kernel with a different
> view of time.
> 
> This doesn't even have to be a VM. There is a lot of non-hypervisor SW
> out there that just hogs EL2 for more or less nefarious purposes (such
> as "protecting" the kernel), and offsetting the counter values is one
> of thing they could do to hide what they are doing.

Thanks for the info.

Manipulating time counter(sched_clock) runtimely doesn't sound like a
good thing. There used to be similar things happened for TSC on x86
platforms, which Thomas has mentioned several times :)

> 
> The other thing is that this change seems to break the sched_clock()
> handover, since the new clock doesn't start where the old one ends.
> This doesn't affect arm64, which can only have one true source of
> time, but other archs would probably suffer from this.

Yes, I has similar concern. And for sched_clock, it usually should be
done by a very low read cost, high precison, and better per-cpu timer.
I only have some knowledge about x86 and arm64, and don't know whether
there is other architecture that really switches sched_clock .

Thanks,
Feng