From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marcelo Tosatti Subject: Re: [patch 13/18] KVM: x86: pass host_tsc to read_l1_tsc Date: Mon, 29 Oct 2012 16:45:41 -0200 Message-ID: <20121029184541.GD30422@amt.cnet> References: <20121024131340.742340256@redhat.com> <20121024131621.890469944@redhat.com> <508E9B1B.20902@parallels.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: kvm@vger.kernel.org, johnstul@us.ibm.com, jeremy@goop.org, zamsden@gmail.com, gleb@redhat.com, avi@redhat.com, pbonzini@redhat.com To: Glauber Costa Return-path: Received: from mx1.redhat.com ([209.132.183.28]:57779 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1760300Ab2J2Sqc (ORCPT ); Mon, 29 Oct 2012 14:46:32 -0400 Content-Disposition: inline In-Reply-To: <508E9B1B.20902@parallels.com> Sender: kvm-owner@vger.kernel.org List-ID: On Mon, Oct 29, 2012 at 07:04:59PM +0400, Glauber Costa wrote: > On 10/24/2012 05:13 PM, Marcelo Tosatti wrote: > > Allow the caller to pass host tsc value to kvm_x86_ops->read_l1_tsc(). > > > > Signed-off-by: Marcelo Tosatti > > Would you mind explaining why? > > it seems to me that rdtscll() here would be perfectly safe: the only > case in which they wouldn't, is in a nested-vm environment running > paravirt-linux with a paravirt tsc. In this case, it is quite likely > that we'll want rdtscll *anyway*, instead of going to tsc directly. Its something different (from a future patch): "KVM added a global variable to guarantee monotonicity in the guest. One of the reasons for that is that the time between 1. ktime_get_ts(×pec); 2. rdtscll(tsc); Is variable. That is, given a host with stable TSC, suppose that two VCPUs read the same time via ktime_get_ts() above. The time required to execute 2. is not the same on those two instances executing in different VCPUS (cache misses, interrupts...)." Think step 1. returning the same value on both vcpus (to read the explanation above).