On Fri, May 15, 2026, [email protected] wrote: > Thank you for your contribution! Sashiko AI review found 1 potential issue(s) > to consider: > > diff --git a/arch/x86/kernel/kvmclock.c b/arch/x86/kernel/kvmclock.c > > index df95516a9d899..006e3a13500b4 100644 > > --- a/arch/x86/kernel/kvmclock.c > > +++ b/arch/x86/kernel/kvmclock.c > [ ... ] > > @@ -178,8 +178,22 @@ static void kvm_register_clock(char *txt) > > pr_debug("kvm-clock: cpu %d, msr %llx, %s", smp_processor_id(), pa, > > txt); > > } > > > > +static void kvmclock_disable(void) > > +{ > > + if (msr_kvm_system_time) > > + native_write_msr(msr_kvm_system_time, 0); > > +} > > + > > static void kvm_save_sched_clock_state(void) > > { > > + /* > > + * Stop host writes to kvmclock immediately prior to suspend/hibernate. > > + * If the system is hibernating, then kvmclock will likely reside at a > > + * different physical address when the system awakens, and host writes > > + * to the old address prior to reconfiguring kvmclock would clobber > > + * random memory. > > + */ > > + kvmclock_disable(); > > } > > Can this lead to memory corruption if another clocksource overwrites the > x86_platform.save_sched_clock_state callback?
Yes, that's why the kernel only allows one "main" hypervisor.
