On Thu, 2026-05-21 at 06:38 -0700, Sean Christopherson wrote: > On Thu, May 21, 2026, Peter Zijlstra wrote: > > On Thu, May 21, 2026 at 05:59:17AM -0700, Sean Christopherson wrote: > > > On Thu, May 21, 2026, David Woodhouse wrote: > > > > 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? > > > > > > Heh, you have no idea. I've been "this" close to creating a VIM binding > > > for a > > > while, it is time... > > > > 'z=' not good enough? > > You people and your fancy ways. I'm just happy I can get in and out of the > editor :-)
I reached the peak of my vi knowledge in about 1995 when I learned that I could log in on another terminal, kill it from there, and then set EDITOR=emacs. Ironically I still find myself doing that kind of thing when I'm composing a git-send-email cover letter and decide I don't want to send the series as-is at all. Maybe there's a way to put a poison pill in the message (or save it unchanged?) to make git *NOT* send anything... but I always err on the side of caution and just nuke it from orbit, or at least from another terminal.
smime.p7s
Description: S/MIME cryptographic signature
