Re: [PATCH] fix kvmclock bug

[Zachary Amsden <zamsden@redhat.com>]

On 09/25/2010 11:54 PM, Jan Kiszka wrote:
> Am 24.09.2010 09:28, Jan Kiszka wrote:
>    
>> Am 19.09.2010 02:15, Zachary Amsden wrote:
>>      
>>> For CPUs with unstable TSC, we null time offset between not just VCPU
>>> switches, but all preemptions of the kvm thread.  This makes a bug much
>>> more likely where the kvmclock values are updated before a successful
>>> exit from virt, causing an underflow.
>>>
>>> The null offsetting was added at : bf0fb4a42ba7eb362f4013bd2e93209666793e66
>>> The underflow happens with this additional patch :
>>> cf839f5da2b0779b9ec8b990f851fb4e7d681da0
>>>
>>> There is a secondary bug, which is that TSC fails to advance with real
>>> time on unstable TSC, but the fix is much more involved (it requires the
>>> TSC catchup code).
>>>
>>> For now, this patch is sufficient to get things working again for me.
>>>        
>> ...but not for me. I still face stuck (or infinitely slow) guests that
>> want to use kvmclock once tsc_unstable gets set. Or is this patch
>> addressing a different issue?
>>      
> Commit bfb3f332 ("TSC catchup mode") in kvm.git finally resolves the
> issue here.
>    

Good to hear that!

> That only leaves us with the likely wrong unstable declaration of the
> TSC after resume. And that raises the question for me if KVM is actually
> that much smarter than the Linux kernel in detecting TSC jumps. If
> something is missing, can't we improve the kernel's detection mechanism
> which already has suspend/resume support?
>    

Linux must make the the conservative choice about TSC being declared 
unstable; if it is possible that it has become unstable, it is 
unstable.  Unfortunately, this bodes not well for us, as most of the 
finer points of accuracy depend on having a stable TSC.

There's a bunch of places that declare TSC unstable, and where in the 
suspend / resume cycle that happens would depend on your actual hardware.

Zach