From mboxrd@z Thu Jan  1 00:00:00 1970
From: Glauber Costa <glommer@redhat.com>
Subject: Re: [PATCH 2/2] turn off kvmclock when resetting cpu
Date: Wed, 5 May 2010 15:21:27 -0300
Message-ID: <20100505182127.GC3443@mothafucka.localdomain>
References: <1272998128-30384-1-git-send-email-glommer@redhat.com>
 <1272998128-30384-2-git-send-email-glommer@redhat.com>
 <1272998128-30384-3-git-send-email-glommer@redhat.com>
 <4BE11DB3.7020901@redhat.com>
 <20100505152402.GA3443@mothafucka.localdomain>
 <4BE18FFE.6040201@redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: kvm@vger.kernel.org, zamsden@redhat.com, mtosatti@redhat.com
To: Avi Kivity <avi@redhat.com>
Return-path: <kvm-owner@vger.kernel.org>
Received: from mx1.redhat.com ([209.132.183.28]:35831 "EHLO mx1.redhat.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1752350Ab0EESVd (ORCPT <rfc822;kvm@vger.kernel.org>);
	Wed, 5 May 2010 14:21:33 -0400
Received: from int-mx05.intmail.prod.int.phx2.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.18])
	by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o45ILX3o001257
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <kvm@vger.kernel.org>; Wed, 5 May 2010 14:21:33 -0400
Content-Disposition: inline
In-Reply-To: <4BE18FFE.6040201@redhat.com>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

On Wed, May 05, 2010 at 06:34:22PM +0300, Avi Kivity wrote:
> On 05/05/2010 06:24 PM, Glauber Costa wrote:
> >On Wed, May 05, 2010 at 10:26:43AM +0300, Avi Kivity wrote:
> >
> >>>+    msr_data.info.nmsrs = n;
> >>>+
> >>>+    return kvm_vcpu_ioctl(env, KVM_SET_MSRS,&msr_data);
> >>>+}
> >>>+
> >>>+
> >>How about a different approach?  Query the supported MSRs
> >>(KVM_GET_MSR_LIST or thereabout) and reset them (with special cases
> >>for the TSC, and the old clock MSRs when the new ones are present)?
> >I didn't went that route because I was unsure that every one of them
> >would be resetable by writing 0 on it.
> 
> There are probably others.  We should reset them correctly anyway.
> 
> It's probably done by generic qemu code so it works.
> 
> >And if we are going to special case the most part of it, then there
> >is no point in doing it.
> >
> >If you think it is doable to special case just the tsc, then I am fine.
> 
> I think if we have the following sequence
> 
>   clear all msrs
>   qemu reset
>   kvm specific msr reset
> 
> Then we'd be fine.
> 
> Oh, and tsc needs to be reset to 0 as well - it isn't a special case.
This means a guest running on a perfectly synchronized tsc host
will not see a sync tsc. Simply because we can't possible
reset all tscs at the same time.