RE: TSC virtualization across different host frequency platform migration

["Dong, Eddie" <eddie.dong@intel.com>]

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.

thx, eddie