On Wed, Jul 16, 2014 at 12:18:37PM +0200, Paolo Bonzini wrote: > Il 16/07/2014 11:52, Igor Mammedov ha scritto: > >There are buggy hosts in the wild that advertise invariant > >TSC and as result host uses TSC as clocksource, but TSC on > >such host sometimes sporadically jumps backwards. > > > >This causes kvmclock to go backwards if host advertises > >PVCLOCK_TSC_STABLE_BIT, which turns off aggregated clock > >accumulator and returns: > > pvclock_vcpu_time_info.system_timestamp + offset > >where 'offset' is calculated using TSC. > >Since TSC is not virtualized in KVM, it makes guest see > >TSC jumped backwards and leads to kvmclock going backwards > >as well. > > > >This is defensive patch that keeps per CPU last clock value > >and ensures that clock will never go backwards even with > >using PVCLOCK_TSC_STABLE_BIT enabled path. > > I'm not sure that a per-CPU value is enough; your patch can make the > problem much less frequent of course, but I'm not sure neither > detection nor correction are 100% reliable. Your addition is > basically a faster but less reliable version of the last_value > logic. > > If may be okay to have detection that is faster but not 100% > reliable. However, once you find that the host is buggy I think the > correct thing to do is to write last_value and kill > PVCLOCK_TSC_STABLE_BIT from valid_flags. > > Did you check that the affected host has the latest microcode? > Alternatively, could we simply blacklist some CPU steppings? I'm > not sure who we could ask at AMD :( but perhaps there is an erratum. > > Paolo Igor, Can we move detection to the host TSC clocksource driver ? Because it is responsability of the host system to provide a non backwards clock_gettime() interface as well. How did you prove its the host TSC in fact going backwards? Is it cross-CPU detection? -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
