From mboxrd@z Thu Jan  1 00:00:00 1970
From: Gerd Hoffmann <kraxel@redhat.com>
Subject: Re: [patch] kvmclock fix
Date: Tue, 03 Feb 2009 18:19:56 +0100
Message-ID: <49887CBC.8010509@redhat.com>
References: <498878A7.4030709@redhat.com> <5d6222a80902030914u77b93f28t81df26ed345717b0@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: KVM list <kvm@vger.kernel.org>
To: Glauber Costa <glommer@gmail.com>
Return-path: <kvm-owner@vger.kernel.org>
Received: from mx2.redhat.com ([66.187.237.31]:33060 "EHLO mx2.redhat.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1752203AbZBCRUJ (ORCPT <rfc822;kvm@vger.kernel.org>);
	Tue, 3 Feb 2009 12:20:09 -0500
In-Reply-To: <5d6222a80902030914u77b93f28t81df26ed345717b0@mail.gmail.com>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

Glauber Costa wrote:
>> +static unsigned int  ref_freq;
>> +static unsigned long loops_per_jiffy_ref;
>> +static unsigned long tsc_khz_ref;
> 
> Doesn't these need to be percpu too ?
> 
> Otherwise we could be calculating the new frequency based on a foreign
> reference.

I doubt you can have a SMP systems with cpus having different freqs.
Also tsc.c does the same.

> I believe a possible approach is to move those that refer to tsc
> calculation to tsc.c, and make all uses
> of tsc_khz comply to a per_cpu use. A global tsc_khz does not make sense anyway.
> 
> Then we'll have a specific kvm notifier that just forces the guest out
> of its execution so we can update
> the clock state.

Then we have an ordering issue with the two notifier calls.  I don't
thing there is a way to force a specific call order.

cheers,
  Gerd