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

[Yao Yuan]

On Thu, Sep 03, 2026 at 08:38:57AM +0800, Marc Zyngier wrote:
> On Thu, 03 Sep 2026 07:51:03 +0100,
> Yao Yuan <yaoyuan@xxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxx> 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.

Thanks for the details !
I see, this yet like some hypervisor hide its handling time
from guest to me :-)

>
> 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, we can discuss this more in Feng's reply, thanks!

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