Messages in this thread | | | Date | Wed, 16 Jul 2014 12:18:37 +0200 | From | Paolo Bonzini <> | Subject | Re: [PATCH] ensure guest's kvmclock never goes backwards when TSC jumps backward |
| |
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
| |