[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.