Re: [patch 0/7] force the TSC unreliable by reporting C2 state

[john stultz <johnstul@us.ibm.com>]

On Wed, 2008-06-18 at 19:41 -0300, Marcelo Tosatti wrote:
> On Wed, Jun 18, 2008 at 04:42:40PM -0500, Anthony Liguori wrote:
> > Marcelo Tosatti wrote:
> >> On Wed, Jun 18, 2008 at 04:02:39PM -0500, Anthony Liguori wrote:
> >>   
> >>>>> Have we yet determined why the TSC is so unstable in the first 
> >>>>> place?   In theory, it should be relatively stable on single-node 
> >>>>> Intel and  Barcelona chips.
> >>>>>             
> >>>> If the host enters C2/C3, or changes CPU frequency, it becomes
> >>>> unreliable as a clocksource and there's no guarantee the guest will
> >>>> detect that.
> >>>>         
> >>> On Intel, the TSC should be fixed-frequency for basically all 
> >>> shipping  processors supporting VT.  Starting with 10h (Barcelona), I 
> >>> believe AMD  also has a fixed frequency TSC.
> >>>     
> >>
> >> But still stops ticking in C2/C3 state, I suppose?
> >>   
> >
> > I don't know for sure but the TSC is not tied to the CPU clock so I  
> > would be surprised if it did.  I think that that would defeat the  
> > utility of a fixed-frequency TSC.
> 
> Well, Linux assumes that TSC stops ticking on C2/C3.
> 
> Section 18.10 of Intel says:
> 
> "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."
> 
> However it does not mention C2/C3.
> 
> Could someone confirm either way?

My understanding: On most systems, the TSC halts in C3. C2 may also halt
the TSC, but that seems to depend on the BIOS.

thanks
-john