RE: [Xen-devel] TSC virtualization across different host frequency platform migration

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

>From: Dong, Eddie 
>Sent: 2009年4月23日 9:29
>
>Dan Magenheimer wrote:
>> Hi Eddie/Kevin --
>> 
>> I'm sorry to be dense, but I don't understand the
>> details of your solution.  I'm also not sure I
>> understand the problem you are trying to solve.
>> The problem description doesn't describe a problem,
>> just an event.
>> 
>> I'm guessing the problem is:  When a guest chooses
>> TSC as its primary clocksource AND a migration later
>> occurs to a host with a different TSC frequency
>> THEN wallclock time (e.g. the "date" command)
>> becomes incorrect.
>
>Mostly yes though don't know if guest wall clock depends on 
>TSC heavily.
>
>> 
>> I'm also guessing that you are NOT trying to solve
>> the problem:  An application that uses TSC
>> heavily to measure the passage of time AND
>> calibrates TSC on host A AND invisibly
>> migrates to host B with a different TSC
>> frequency THEN will NOT be able to accurately
>> measure the passage of time.  However, it will
>> continue to be monotonically increasing.
>
>Yes, if we don't scale the TSC.
>The proposal tries to solve the problem.
>
>We can use software trap and emulate to scale the TSC so
>that guest TSC after migration is same with that before migration.
>
>But this is not optimial since the overhead may be too high. So we 
>propose to use smart scaling, which continuously use TSC_OFFSET,
>but adjust the TSC_OFFSET value time to time (today it is fixed), 
>so that an application that uses TSC heavily to measure the 
>passage of time
>can get correct time.
>

So we're really not trying to solve the micro-level accuracy if app
tries to use TSC for that purpose, which always bias from bare
metal as long as running in a VM. Here we're trying to ensure
macro-level accuracy and thus ToD in guest after migration, with 
performance optimized if app in VM uses gettimeofday frequently. 
In that way, gap between trap vs. notrap would be orders of 
magnitude. 

Thanks
Kevin

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel