From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [PATCH] fix kvmclock bug Date: Sun, 26 Sep 2010 11:54:17 +0200 Message-ID: <4C9F1849.1050801@web.de> References: <4C95560D.3050108@redhat.com> <4C9C5309.5080403@web.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig063B1B2F147B9CB12BA6D77A" Cc: Marcelo Tosatti , Avi Kivity , kvm , Glauber Costa To: Zachary Amsden Return-path: Received: from fmmailgate02.web.de ([217.72.192.227]:58321 "EHLO fmmailgate02.web.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755015Ab0IZJyX (ORCPT ); Sun, 26 Sep 2010 05:54:23 -0400 In-Reply-To: <4C9C5309.5080403@web.de> Sender: kvm-owner@vger.kernel.org List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig063B1B2F147B9CB12BA6D77A Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 muc= h >> more likely where the kvmclock values are updated before a successful >> exit from virt, causing an underflow. >> >> The null offsetting was added at : bf0fb4a42ba7eb362f4013bd2e932096667= 93e66 >> The underflow happens with this additional patch :=20 >> 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 t= he >> TSC catchup code). >> >> For now, this patch is sufficient to get things working again for me. >=20 > ...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 --------------enig063B1B2F147B9CB12BA6D77A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAkyfGE0ACgkQitSsb3rl5xTPvACgwrUOLpEiA+kxxFBgFMMuX5A5 3V4AoOiSPizIxidXVd1TRClUQU4bmD/U =m/iz -----END PGP SIGNATURE----- --------------enig063B1B2F147B9CB12BA6D77A--