On Fri, 2026-05-15 at 12:19 -0700, Sean Christopherson wrote: > Pass in a PV clock's save/restore helpers when configuring sched_clock > instead of relying on each PV clock to manually set the save/restore hooks. > In addition to bringing sanity to the code, this will allow gracefully > "rejecting" a PV sched_clock, e.g. when running as a CoCo guest that has > access to a "secure" TSC. > > No functional change intended. > > Signed-off-by: Sean Christopherson <[email protected]>
Nice! Reviewed-by: David Woodhouse <[email protected]> > --- a/arch/x86/xen/time.c > +++ b/arch/x86/xen/time.c > @@ -567,13 +567,12 @@ static void __init xen_init_time_common(void) > { > xen_sched_clock_offset = xen_clocksource_read(); > static_call_update(pv_steal_clock, xen_steal_clock); > - paravirt_set_sched_clock(xen_sched_clock); > + > /* > * Xen has paravirtualized suspend/resume and so doesn't use the common > * x86 sched_clock save/restore hooks. > */ > - x86_platform.save_sched_clock_state = NULL; > - x86_platform.restore_sched_clock_state = NULL; > + paravirt_set_sched_clock(xen_sched_clock, NULL, NULL); > > tsc_register_calibration_routines(xen_tsc_khz, NULL); > x86_platform.get_wallclock = xen_get_wallclock; Same deal here as with kvmclock, FWIW. If the TSC is viable, then it's the better choice. Especially now there's a significant chance that a "Xen guest" is actually running under KVM. Xen never screwed its pvclock up quite as much as KVM did :)
smime.p7s
Description: S/MIME cryptographic signature
Amazon Development Centre (London) Ltd. Registered in England and Wales with registration number 04543232 with its registered office at 1 Principal Place, Worship Street, London EC2A 2FA, United Kingdom.
