From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: Bug in KVM clock backwards compensation Date: Thu, 28 Apr 2011 09:06:01 +0200 Message-ID: <4DB911D9.3010409@web.de> References: <4DB9106D.6040203@redhat.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig708D9A3736D8C7C8C364ED6C" Cc: kvm , Joerg Roedel To: Zachary Amsden Return-path: Received: from fmmailgate02.web.de ([217.72.192.227]:34250 "EHLO fmmailgate02.web.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754526Ab1D1HHs (ORCPT ); Thu, 28 Apr 2011 03:07:48 -0400 In-Reply-To: <4DB9106D.6040203@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig708D9A3736D8C7C8C364ED6C Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2011-04-28 08:59, Zachary Amsden wrote: > So I've been going over the new code changes to the TSC related code an= d > I don't like one particular set of changes. In particular, here: >=20 > kvm_x86_ops->vcpu_load(vcpu, cpu); > if (unlikely(vcpu->cpu !=3D cpu) || check_tsc_unstable()) { > /* Make sure TSC doesn't go backwards */ > s64 tsc_delta; > u64 tsc; >=20 > kvm_get_msr(vcpu, MSR_IA32_TSC, &tsc); > tsc_delta =3D !vcpu->arch.last_guest_tsc ? 0 : > tsc - vcpu->arch.last_guest_tsc; >=20 > if (tsc_delta < 0) > mark_tsc_unstable("KVM discovered backwards TSC= "); > if (check_tsc_unstable()) { > kvm_x86_ops->adjust_tsc_offset(vcpu, -tsc_delta= ); > vcpu->arch.tsc_catchup =3D 1; > } >=20 >=20 > The point of this code fragment is to test the host clock to see if it > is stable, because we may have just come back from an idle phase which > stopped the TSC, switched CPUs, or come back from a deep sleep state > which reset the host TSC. >=20 > However, the above code is fetching the guest TSC instead of the host > TSC, which isn't the way it is supposed to work. >=20 > I saw a patch floating around that touched this code recently, but I > think there's a definite issue here that needs addressing. And /me still wonders (like I did when this first popped up) if the proper place of determining TSC stability really have to be KVM. If the Linux core fails to detect some instability and KVM has to jump in, shouldn't we better improve the core's detection abilities and make use of them in KVM? Conceptually this looks like we are currently just working around a core deficit in KVM. Jan --------------enig708D9A3736D8C7C8C364ED6C 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/ iEYEARECAAYFAk25EdsACgkQitSsb3rl5xRApACg6n7u/gdIzvGT3gKOWorXmnjC G4UAn3Xg7d862PD63NURiuycE2YKvCs4 =i17z -----END PGP SIGNATURE----- --------------enig708D9A3736D8C7C8C364ED6C--