On Tue, Mar 04, 2025, Michael Kelley wrote: > From: Sean Christopherson <seanjc@xxxxxxxxxx> Sent: Wednesday, February 26, 2025 6:18 PM > > > > Register the Hyper-V timer callbacks or saving/restoring its PV sched_clock > > s/or/for/ > > > if and only if the timer is actually being used for sched_clock. > > Currently, Hyper-V overrides the save/restore hooks if the reference TSC > > available, whereas the Hyper-V timer code only overrides sched_clock if > > the reference TSC is available *and* it's not invariant. The flaw is > > effectively papered over by invoking the "old" save/restore callbacks as > > part of save/restore, but that's unnecessary and fragile. > > The Hyper-V specific terminology here isn't quite right. There is a > PV "Hyper-V timer", but it is loaded by the guest OS with a specific value > and generates an interrupt when that value is reached. In Linux, it is used > for clockevents, but it's not a clocksource and is not used for sched_clock. > The correct Hyper-V term is "Hyper-V reference counter" (or "refcounter" > for short). The refcounter behaves like the TSC -- it's a monotonically > increasing value that is read-only, and can serve as the sched_clock. > > And yes, both the Hyper-V timer and Hyper-V refcounter code is in a > source file with a name containing "timer" but not "refcounter". But > that seems to be the pattern for many of the drivers in > drivers/clocksource. :-) Heh, wading through misleading naming is basically a right of passage in the kernel. Thanks for the reviews and testing! I'll fixup all the changelogs.
