From mboxrd@z Thu Jan 1 00:00:00 1970 From: Zachary Amsden Subject: Re: [PATCH 09/18] Robust TSC compensation Date: Tue, 13 Jul 2010 11:45:51 -1000 Message-ID: <4C3CDE8F.60304@redhat.com> References: <1278987938-23873-1-git-send-email-zamsden@redhat.com> <1278987938-23873-10-git-send-email-zamsden@redhat.com> <20100713203418.GA903@amt.cnet> <4C3CD77B.9050108@redhat.com> <4C3CDDD4.6010009@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Marcelo Tosatti , KVM , Avi Kivity , Glauber Costa , Linux-kernel To: "David S. Ahern" Return-path: In-Reply-To: <4C3CDDD4.6010009@cisco.com> Sender: linux-kernel-owner@vger.kernel.org List-Id: kvm.vger.kernel.org On 07/13/2010 11:42 AM, David S. Ahern wrote: > > On 07/13/10 15:15, Zachary Amsden wrote: > > >>> What prevents a vcpu from seeing its TSC go backwards, in case the first >>> write in the 5 second window is smaller than the victim vcpu's last >>> visible TSC value ? >>> >>> >> Nothing, unfortunately. However, the TSC would already have to be out >> of sync in order for the problem to occur. It can never happen in >> normal circumstances on a stable hardware TSC except in one case; >> migration. During the CPU state transfer phase of migration, however, >> > What about across processor sockets? Aren't CPUs brought up at different > points such that their TSCs start at different times? > Yes, that's called an unsynchronized TSC. In that case, the compensation does the best it can based on time since the first TSC write, but it will never be exact.