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>, 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:41:20 +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:41:49 -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>
References: <13d04f6f-9469-4644-a735-0ec846433397@default> <C5FE22BB.6E54%keir.fraser@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acm0q3HSSZiKszrATIOXS9rDQ0InwgBGJPUmAAlXxiA=
Thread-topic: [Xen-devel] Time skew on HP DL785 (and possibly other boxes)
>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
assured with affinity to one node or several nodes with known
same frequency...

Xen-devel mailing list