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

[Marc Zyngier <maz@kernel.org>]

On Thu, 03 Sep 2026 07:51:03 +0100,
Yao Yuan <yaoyuan@linux.alibaba.com> wrote:
> 
> On Wed, Sep 02, 2026 at 04:32:25PM +0800, Marc Zyngier wrote:
> > On Wed, 02 Sep 2026 09:21:23 +0100,
> > Feng Tang <feng.tang@linux.alibaba.com> wrote:
> > >
> > > Currently sched_clock shows the relative time to the boot starting of
> > > kernel, while there could be long firmware start time before it and
> > > after the hardware reset.
> > >
> > > On modern server platforms, there could be several software running in
> > > parallel. Like for arm64, it could have  SCP (System Control Processor)
> > > firmware running on SCP processor, and ATF (Arm Trusted Firmware) and
> > > Linux OS on the main processor.
> > >
> > > Debugging some nasty issues on these platform may need to cross-check
> > > the logs from these firmwares and Linux kernel for specific events,
> > > where a unified reference timeline is critical. All these software can
> > > read the hardware timer, which is also the base of sched_clock for
> > > Linux kernel. Using the absolute counter since hardware timer reset
> > > makes it possible for all kinds of software to have a same time base.
> > >
> > > Add 'abs_sched_clock' parameter to provide an option for using absolute
> > > counter, and users should make sure their sched_clock (hardware timer)
> > > is capable of supporting absolute counter before enabling the option.
> > >
> > > Locally, it did help on chasing some RAS issues which needed cooperation
> > > between kernel, SCP firmware and ATF, by mapping the actions from each
> > > players into one timeline based on the timestamps in their logs.
> >
> > I really have to ask: why isn't this just a one-off sampling of the
> > counter, kept in some user accessible location (debugfs or something
> > else), and ultimately post-processed to align your logs? People have
> > been doing this... forever, and that has been "good enough" so far.
> >
> 
> 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.

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.

	M.

-- 
Jazz isn't dead. It just smells funny.