Re: [RFC] fix VMX TSC synchronicity

[Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org>]

Alexander Graf wrote:
>>>   
>>>     
>>>       
>> What I mean is, right now we present really broken tscs to the guest.  
>> After your patch, we present less-broken tscs (at boot, they will 
>> closely resemble stable tscs).  But after the machine idles a bit and 
>> cpufreq takes over, the tscs won't be stable any more.
>>
>>   
>>     
>
> Why would the TSC break due to cpufreq? This patchset was against VMX,
> which is only available on current Intel CPUs. All of those guarantee a
> constant TSC increase at the maximum frequency.
>
> Also see the Intel Documentation:
>
> Vol. 3 18-37
>
> For Pentium 4 processors, Intel Xeon processors (family [0FH], models
> [03H and higher]); for Intel Core Solo and Intel Core Duo processors
> (family [06H], model [0EH]); for the Intel Xeon processor 5100 series
> and Intel Core 2 Duo processors (family [06H], model [0FH]): the
> time-stamp counter increments at a constant rate. That rate may be set
> by the maximum core-clock to bus-clock ratio of the processor or may be
> set by the maximum resolved frequency at which the processor is booted.
> The maximum resolved frequency may differ from the maximum qualified
> frequency of the processor, see Section 18.17.5 for more
> detail.
> The specific processor configuration determines the behavior. Constant
> TSC behavior ensures that the duration of each clock tick is uniform and
> supports the use of the TSC as a wall clock timer even if the processor
> core changes frequency.
> This is the architectural behavior moving forward.

Thanks; that's reassuring to know that it will work (at least on Intel).

-- 
error compiling committee.c: too many arguments to function


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/