This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


RE: [Xen-devel] Time skew on HP DL785 (and possibly other boxes)

To: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>, Ian Pratt <Ian.Pratt@xxxxxxxxxxxxx>
Subject: RE: [Xen-devel] Time skew on HP DL785 (and possibly other boxes)
From: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>
Date: Mon, 6 Apr 2009 14:34:27 +0000 (GMT)
Cc: john.v.morris@xxxxxx, "Tian, Kevin" <kevin.tian@xxxxxxxxx>, "Xen-Devel \(E-mail\)" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Mon, 06 Apr 2009 07:35:05 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C5FE22BB.6E54%keir.fraser@xxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
> > The goal for Xen timekeeping is to ensure that if a guest
> > could somehow magically read any of its virtual clocks
> > (tsc, pit, hpet, pmtimer, ??) on all its virtual processors
> > simultaneously, the values read must always obey this
> > "virtual clock law":
> We can do this for all except TSC for HVM guests because 

I understand that this is true IFF Xen system time itself
obeys the virtual clock law.  I am concerned that maybe
it cannot on machines such as this.  If not, NO HVM guest
clock will obey the law, correct?

> Everything else builds on Xen system time, and Xen system 
> time should just
> require each CPU's TSC to be individually stable.
> ...I think the benefit of your patch was in 
> sync'ing system
> time across all CPUs at the same time, which significantly 
> reduced maximum divergence.

The problem was, in our testing on this DL785, the maximum
divergence was not reduced enough!  This was tested with
xen-unstable (not sure what c/s).

> One concern I have however, is Intel's 

It's possible that this (or some other problem) has resulted
in the divergenece on the DL785.  So more testing is in


Xen-devel mailing list