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 :)
smime.p7s
Description: S/MIME cryptographic signature
