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: "Tian, Kevin" <kevin.tian@xxxxxxxxx>, Keir Fraser <keir.fraser@xxxxxxxxxxxxx>, Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>, Ian Pratt <Ian.Pratt@xxxxxxxxxxxxx>
Subject: RE: [Xen-devel] Time skew on HP DL785 (and possibly other boxes)
From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Date: Sun, 5 Apr 2009 20:43:22 +0800
Accept-language: en-US
Acceptlanguage: en-US
Cc: "john.v.morris@xxxxxx" <john.v.morris@xxxxxx>, "Xen-Devel \(E-mail\)" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Sun, 05 Apr 2009 05:43:51 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <0A882F4D99BBF6449D58E61AAFD7EDD61024D382@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
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>
References: <13d04f6f-9469-4644-a735-0ec846433397@default> <C5FE22BB.6E54%keir.fraser@xxxxxxxxxxxxx> <0A882F4D99BBF6449D58E61AAFD7EDD61024D382@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acm0q3HSSZiKszrATIOXS9rDQ0InwgBGJPUmAAlXxiAAAKeesA==
Thread-topic: [Xen-devel] Time skew on HP DL785 (and possibly other boxes)
>From: Tian, Kevin
>Sent: 2009年4月5日 20:41
>>From: Keir Fraser [mailto:keir.fraser@xxxxxxxxxxxxx] 
>>Sent: 2009年4月5日 15:56
>>On 03/04/2009 23:23, "Dan Magenheimer" 
>><dan.magenheimer@xxxxxxxxxx> wrote:
>>> I think I still have a real concern here.  Let me see if
>>> I can explain.
>>> 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 there 
>>virtual TSC
>>is hardwired onto the physical TSC (plus a configurable 
>>offset). If TSCs run
>>at significantly different rates then that will be hard to 
>>hide from the
>>guest. Luckily Windows is pretty robust to iffy timers, and no doubt
>>particularly suspicious of TSCs in multiprocessor environments.
>In that case then Xen'd better figure out some hints to have
>HVM guest recognize TSC as unreliable timer source, and 
>then fall back to other virtual platform timers (since even keeping
>tsc still require emulation for every access now, which would
>give wrong illusion to guest and also be harder to be accurately
>emulated due to assumed high frequency). Although extra
>overhead could be incurred, that's the fact if HVM can be
I meant 'can't be' here.

>assured with affinity to one node or several nodes with known
>same frequency...
Xen-devel mailing list