From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [patch 3/3] KVM: VMX: initialize TSC offset relative to vm creation time Date: Thu, 11 Dec 2008 19:38:24 +0200 Message-ID: <49415010.3000108@redhat.com> References: <20081209011247.570596925@localhost.localdomain> <20081209012212.171143870@localhost.localdomain> <493F97B0.2060104@redhat.com> <20081210165307.GA28365@dmt.cnet> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org, Benjamin Serebrin To: Marcelo Tosatti Return-path: Received: from mx2.redhat.com ([66.187.237.31]:60674 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756740AbYLKRi3 (ORCPT ); Thu, 11 Dec 2008 12:38:29 -0500 In-Reply-To: <20081210165307.GA28365@dmt.cnet> Sender: kvm-owner@vger.kernel.org List-ID: Marcelo Tosatti wrote: >> This looks fine, but have you tested it on a host with unsync tsc? I'm >> worried that we'll get regressions there even on uniprocessor guest. >> I'd like to keep the current behaviour for the special case of >> uniprocessor guest on unsync tsc host. >> > > I don't see how. For UP guests the TSC is initialized to zero during > vcpu setup, similarly to the current behaviour. > > Can you explain? > > On a host with an unsync tsc, when you move the vcpu to another cpu, the tsc may jump backwards. >> There's a further improvement possible: treating the tsc as shared among >> all vcpus, so that a guest write to one will update all of them, like on >> a hyperthreaded core. This will prevent the unsyncing caused by the >> host trying to sync tscs, and the vcpu being scheduled away at the same >> time. >> > > You mean the guest trying to sync tscs? Indeed, that is sensitive to > scheduling (like most of the calibration algorithms that are time > sensitive). Yes. > Your suggestion differs from the behaviour of actual > hardware, though. > It's similar to how hyperthreaded cpus work, so there is precedent. > Anyway, this patch is trivial, and an improvement compared to the > current situation. > I'm worried that it will regress for single vcpu guests on unsync tsc hosts. > What are the possible implications of simply not zeroing the guest TSC ? > Guests will have access to the hosts TSC value, but how bad that is? > We need to set the guest tsc anyway for live migration, so we may as well reset it on startup. It's not a correctness issue, just seems cleaner that way. -- error compiling committee.c: too many arguments to function