From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: vread in kvm_clock Date: Mon, 20 Dec 2010 08:16:22 +0200 Message-ID: <4D0EF4B6.7010908@redhat.com> References: <4D092225.3000300@klipix.org> <4D0BA159.5050400@redhat.com> <4D0E2459.7060907@redhat.com> <4D0EAE28.7070103@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]:20740 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752838Ab0LTGQ3 (ORCPT ); Mon, 20 Dec 2010 01:16:29 -0500 In-Reply-To: <4D0EAE28.7070103@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 12/20/2010 03:15 AM, Zachary Amsden wrote: > 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. Why? > > The tsc multiplier does not look usable for virtualization, btw. Why? -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.