From mboxrd@z Thu Jan  1 00:00:00 1970
From: Glauber Costa <gcosta@redhat.com>
Subject: Re: pv clock: kvm is incompatible with xen :-(
Date: Thu, 24 Apr 2008 09:57:45 -0300
Message-ID: <481083C9.7010406@redhat.com>
References: <47FF1441.6010801@redhat.com> <47FF545C.3010107@qumranet.com>
	<47FF6B43.1070305@redhat.com> <47FFB5B9.2020904@goop.org>
	<4808AF8C.5010500@redhat.com> <48091F6D.7030600@goop.org>
	<480C42E0.3040307@redhat.com> <480C7E82.1010402@goop.org>
	<480C8D8E.6000305@redhat.com> <480E266C.4@redhat.com>
	<480ED13E.6000601@redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Cc: kvm-devel <kvm-devel@lists.sourceforge.net>,
	Jeremy Fitzhardinge <jeremy@goop.org>, Avi Kivity <avi@qumranet.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Return-path: <kvm-devel-bounces@lists.sourceforge.net>
In-Reply-To: <480ED13E.6000601@redhat.com>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/kvm-devel>,
	<mailto:kvm-devel-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=kvm-devel>
List-Post: <mailto:kvm-devel@lists.sourceforge.net>
List-Help: <mailto:kvm-devel-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/kvm-devel>,
	<mailto:kvm-devel-request@lists.sourceforge.net?subject=subscribe>
Sender: kvm-devel-bounces@lists.sourceforge.net
Errors-To: kvm-devel-bounces@lists.sourceforge.net
List-Id: kvm.vger.kernel.org

Gerd Hoffmann wrote:
> Glauber Costa wrote:
>> Gerd Hoffmann wrote:
>>> Jeremy Fitzhardinge wrote:
>>>> Xen could change the parameters in the instant after
>>>> get_time_values(). That change could be as a result of
>>>> suspend-resume, so the parameters
>>>> and the tsc could be wildly different.
>>> Ah, ok, forgot the rdtsc in the picture.  With that in mind I fully
>>> agree that the loop is needed.  I think kvm guests can even hit that one
>>> with the vcpu migrating to a different physical cpu, so we better handle
>>> it correctly ;)
>> It's probably not needed for kvm, since we update everything everytime
>> we get scheduled in the host side, which would cover the case for
>> migration between physical cpus. 
> 
> No, it wouldn't.  The corner case we must catch is: guest reads time
> info, kvm reschedules the guest to another pcpu, guest reads the tsc.
> The time info used by the guest for the tsc delta is stale then, it
> belongs to the previous pcpu.
> 
> cheers,
>   Gerd
> 
Agreed.

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone