From mboxrd@z Thu Jan 1 00:00:00 1970 From: Zachary Amsden Subject: Re: vread in kvm_clock Date: Fri, 17 Dec 2010 07:43:53 -1000 Message-ID: <4D0BA159.5050400@redhat.com> References: <4D092225.3000300@klipix.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org To: Julien Desfossez Return-path: Received: from mx1.redhat.com ([209.132.183.28]:57360 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754202Ab0LQRn6 (ORCPT ); Fri, 17 Dec 2010 12:43:58 -0500 In-Reply-To: <4D092225.3000300@klipix.org> Sender: kvm-owner@vger.kernel.org List-ID: 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. Zach