Re: [PATCH] fix kvmclock bug

[Jan Kiszka <jan.kiszka@web.de>]

[-- Attachment #1: Type: text/plain, Size: 1399 bytes --]

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.

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?

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]