From mboxrd@z Thu Jan 1 00:00:00 1970 From: Zachary Amsden Subject: Re: vread in kvm_clock Date: Sun, 19 Dec 2010 15:15:20 -1000 Message-ID: <4D0EAE28.7070103@redhat.com> References: <4D092225.3000300@klipix.org> <4D0BA159.5050400@redhat.com> <4D0E2459.7060907@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: Avi Kivity Return-path: Received: from mx1.redhat.com ([209.132.183.28]:59159 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752232Ab0LTBP1 (ORCPT ); Sun, 19 Dec 2010 20:15:27 -0500 In-Reply-To: <4D0E2459.7060907@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 12/19/2010 05:27 AM, Avi Kivity wrote: > 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. Even then, we need an atomic in the vread path. The tsc multiplier does not look usable for virtualization, btw. Zach