Re: [PATCH v7 17/36] KVM: x86: Allow KVM master clock mode when TSCs are offset from each other

On Tue, 2026-08-11 at 10:28 -0700, Sean Christopherson wrote:
> On Tue, Aug 11, 2026, David Woodhouse wrote:
> > On Tue, 2026-08-11 at 09:40 -0700, Sean Christopherson wrote:
> > > 
> > > > 
> > > > FWIW in my local tree I've just extended the pvclock_migration_test to
> > > > test precisely the thing you were concerned about: three vCPUs with
> > > > divergent TSC offsets, migrated by setting each vCPU's TSC and then
> > > > invoking KVM_SET_CLOCK_GUEST once, through vCPU0. 
> > > 
> > > I wasn't actually concerned about migration, I was concerned about time going
> > > backwards from the guest's perspective.
> > 
> > But KVM_[SG]ET_CLOCK_GUEST is *purely* for migration. 
> 
> Huh?  I raised my concern in the context of "Allow KVM master clock mode when
> TSCs are offset from each other", and AFAICT, nothing ensures that won't cause
> problems.
> 
> Aaah, it clears PVCLOCK_TSC_STABLE_BIT and relies on the guest to clean up the
> mess.  So the guest won't see time go backwards, but it could see time stop for
> an extended duration, or jump forward.

It shouldn't. Each vCPU gets its *own* pvclock structure, tailored to
*its* offset. They should all see *identical* results.

But yeah, if the guest does that then we can't set the
PVCLOCK_TSC_STABLE_BIT.
> 
> > And your variant just added a dependency on wallclock time back into it
> 
> Can you elaborate?  I'm guessing I don't entirely understand what you mean by
> wallclock time.

The system_time field? The unspecified might-be-UTC-might-have-leap-
seconds one :)