On Fri, 2026-05-15 at 12:19 -0700, Sean Christopherson wrote: > In anticipation of making x86_cpuinit.early_percpu_clock_init(), i.e. > kvm_setup_secondary_clock(), a dedicated sched_clock hook that will be > invoked if and only if kvmclock is set as sched_clock, ensure APs enable > their kvmclock during CPU online. While a redundant write to the MSR is > technically ok, skip the registration when kvmclock is sched_clock so that > it's somewhat obvious that kvmclock *needs* to be enabled during early > bringup when it's being used as sched_clock. > > Plumb in the BSP's resume path purely for documentation purposes. Both > KVM (as-a-guest) and timekeeping/clocksource hook syscore_ops, and it's > not super obvious that using KVM's hooks would be flawed. E.g. it would > work today, because KVM's hooks happen to run after/before timekeeping's > hooks during suspend/resume, but that's sheer dumb luck as the order in > which syscore_ops are invoked depends entirely on when a subsystem is > initialized and thus registers its hooks. > > Opportunsitically make the registration messages more precise to help > debug issues where kvmclock is enabled too late.
That's a hard word to type, isn't it?
> Opportunstically WARN in kvmclock_{suspend,resume}() to harden against
> future bugs.
So is that :)
> Signed-off-by: Sean Christopherson <[email protected]>
Reviewed-by: David Woodhouse <[email protected]>
smime.p7s
Description: S/MIME cryptographic signature
