From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marcelo Tosatti Subject: Re: KVM clock synchronization Date: Wed, 5 Jan 2011 10:17:12 -0200 Message-ID: <20110105121712.GA708@amt.cnet> References: <1293601100-32109-1-git-send-email-zamsden@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: kvm@vger.kernel.org To: Zachary Amsden Return-path: Received: from mx1.redhat.com ([209.132.183.28]:50795 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751871Ab1AEMaQ (ORCPT ); Wed, 5 Jan 2011 07:30:16 -0500 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id p05CUF6T029040 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 5 Jan 2011 07:30:16 -0500 Content-Disposition: inline In-Reply-To: <1293601100-32109-1-git-send-email-zamsden@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On Tue, Dec 28, 2010 at 07:38:16PM -1000, Zachary Amsden wrote: > A further set of improvements to KVM clock. Now it actually can > stay synchronized on SMP systems with a stable TSC, does not get > destabilized by host suspend, and is resistant to migration. > > I did look a bit into the second to last remaining migration issue; > that is, we read the TSCs for all VCPUs at different times, then > write them back at different times as well. We have compensation > for this already (see patch 1), but there is a possibility that > ordering issues create a backwards condition: > > read VTSC-0 > stop VCPU-0 > read VTSC-1 > stop VCPU-1 > > In that case, what the compensation code does is reset VTSC-1 > back to VTSC-0. With the above ordering, this is broken. > > However, in QEMU, the migration order is: > > stop VCPU-0 > stop VCPU-1 > read VTSC-0 > read VTSC-1 > > So even if a higher TSC value is read for VTSC-1, no backwards > condition can be generated, as VCPU-1 was not running at the time > and thus could not have observed the higher TSC. > > This brings us close to having a perfect KVM clock. > > Next steps will be testing to see if this in practice allows us > to drop the atomic backwards protection for KVM clock, and if so, > to implement vread so we have fast system calls for time. > > Zach Patchset looks good to me.