From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: vread in kvm_clock Date: Sun, 19 Dec 2010 17:27:21 +0200 Message-ID: <4D0E2459.7060907@redhat.com> References: <4D092225.3000300@klipix.org> <4D0BA159.5050400@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Julien Desfossez , kvm@vger.kernel.org To: Zachary Amsden Return-path: Received: from mx1.redhat.com ([209.132.183.28]:32249 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932256Ab0LSP11 (ORCPT ); Sun, 19 Dec 2010 10:27:27 -0500 In-Reply-To: <4D0BA159.5050400@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 12/17/2010 07:43 PM, Zachary Amsden wrote: > On 12/15/2010 10:16 AM, Julien Desfossez wrote: >> Hi, >> >> I'm currently working with the kvm clocksource and I'm wondering if >> we could implement the vread function for this clock source when we >> are running on a host with constant_tsc. >> If I understand correctly the hv_clock structure is per_cpu because >> of the eventual frequency changes, but in the case of constant_tsc >> (and after validation that the TSC is synchronized across all the >> cores) I think we could have a working vread function. >> >> In case of migration, could we have a fallback in case we detect we >> end up on a CPU without constant_tsc ? >> >> Any advice/explanation would be greatly appreciated ! > > It's a bit more complex than that. In addition to the problem you > mention with migration, even if the TSC is synchronized, the kvmclock > still is not, even with constant_tsc. There is measurement error in > between reading the TSC and computing the per_cpu hv_clock offset > which varies between CPUs. > What about using rdtscp? We could also disable kvmclock if constant_tsc and migration is not desired, or if constant_tsc and the new tsc multiplier on bulldozers is available on all machines in the migration cluster. -- error compiling committee.c: too many arguments to function