|
xen-devel
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
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
Home