From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marcelo Tosatti Subject: Re: [patch 3/3] KVM: VMX: initialize TSC offset relative to vm creation time Date: Wed, 10 Dec 2008 17:53:07 +0100 Message-ID: <20081210165307.GA28365@dmt.cnet> References: <20081209011247.570596925@localhost.localdomain> <20081209012212.171143870@localhost.localdomain> <493F97B0.2060104@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: kvm@vger.kernel.org, Benjamin Serebrin To: Avi Kivity Return-path: Received: from mx2.redhat.com ([66.187.237.31]:60431 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754702AbYLJTzN (ORCPT ); Wed, 10 Dec 2008 14:55:13 -0500 Content-Disposition: inline In-Reply-To: <493F97B0.2060104@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On Wed, Dec 10, 2008 at 12:19:28PM +0200, Avi Kivity wrote: > Marcelo Tosatti wrote: >> VMX initializes the TSC offset for each vcpu at different times, and >> also reinitializes it for vcpus other than 0 on APIC SIPI message. >> >> This bug causes the TSC's to appear unsynchronized in the guest, even if >> the host is good. >> >> Older Linux kernels don't handle the situation very well, so >> gettimeofday is likely to go backwards in time: >> >> http://www.mail-archive.com/kvm@vger.kernel.org/msg02955.html >> http://sourceforge.net/tracker/index.php?func=detail&aid=2025534&group_id=180599&atid=893831 >> >> Fix it by initializating the offset of each vcpu relative to vm creation >> time, and moving it from vmx_vcpu_reset to vmx_vcpu_setup, out of the >> APIC MP init path. >> > > 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? > 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). Your suggestion differs from the behaviour of actual hardware, though. Anyway, this patch is trivial, and an improvement compared to the current situation. 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?