Re: [RFC] fix VMX TSC synchronicity

Amit Shah
2008-01-15T18:29:17Z

On Tuesday 15 January 2008 23:16:46 Avi Kivity wrote:
> Alexander Graf wrote:
> > If I remember correctly, there was a statement on LKML by AMD which said
> > that the TSC is completely broken on AMD systems, so you should not use
> > it there anyway.
>
> Well, that's up to the guest to decide. Looks like older Linux guests
> make the wrong decision.

http://lkml.org/lkml/2005/11/4/173

That talks about AMD's TSC plans (dated 2005), but it's possible to find out
whether it's a monotonically-increasing source. Basically some revisions of
AMD family F onwards should support this feature:

Future TSC Directions and Solutions
===================================
Future AMD processors will provide a TSC that is P-state and
C-State invariant and unaffected by STPCLK-throttling. This
will make the TSC immune to drift. Because using the TSC
for fast timer APIs is a desirable feature that helps
performance, AMD has defined a CPUID feature bit that
software can test to determine if the TSC is
invariant. Issuing a CPUID instruction with an %eax register
value of 0x8000_0007, on a processor whose base family is
0xF, returns "Advanced Power Management Information" in the
%eax, %ebx, %ecx, and %edx registers. Bit 8 of the return
%edx is the "TscInvariant" feature flag which is set when
TSC is P-state, C-state, and STPCLK-throttling invariant; it
is clear otherwise.

The rate of the invariant TSC is implementation-dependent
and will likely *not* be the frequency of the processor
core; however, its period should be short enough such that
it is not possible for two back-to-back rdtsc instructions
to return the same value. Software which is trying to
measure actual processor frequency or cycle-performance
should use Performance Event 76h, CPU Clocks not Halted,
rather than the TSC to count CPU cycles.