On Wed, 2026-05-27 at 10:30 +0200, Vitaly Kuznetsov wrote: > David Woodhouse <[email protected]> writes: > > ... > > > > > Then in 2018, Vitaly Kuznetsov added Hyper-V TSC page support in > > commit b0c39dc68e3b ("x86/kvm: Pass stable clocksource to guests when > > running nested on Hyper-V"), which extended vgettsc() to handle the > > HVCLOCK case. > > > > I'd quite like to kill it all with fire and make KVM use > > ktime_get_snapshot() instead. > > The main motivation is reducing the complexity of KVM's timekeeping code > I guess?
Reduce the complexity, and clean it up to use the core kernel snapshot facility as $DEITY intended, yes. > The statement "TSC isn't reliable" deserves a book of its own :-) ... deserves a whole wing in a rehab facility... Thanks for the clarification. > > One simple option that occurs to me would be to add a 'cycles_raw' > > value to the system_time_snapshot, for PV clocksources like hyperv and > > kvmclock to populate with the original TSC reading. > > Personally, I don't see this as such an ugly hack. Yeah, having thrown that together last night to see what it looks like, I'm not all that unhappy with it. And it does indeed let me provide precise vmclock paired time when the clocksource is kvmclock, too. There are probably some details to tweak, and I'm sure Thomas will call me a moron again, but I think it's worth it for the resulting cleanup :)
smime.p7s
Description: S/MIME cryptographic signature
