Zachary Amsden <zamsden@xxxxxxxxxx> writes: I think listing all the obscure bits in the PIT was an attempt to weed out the weak and weary readers early, right? > +this as well. Several hardware limitations make the problem worse - if it is > +not possible to write the full 32-bits of the TSC, it may be impossible to > +match the TSC in newly arriving CPUs to that of the rest of the system, > +resulting in unsynchronized TSCs. This may be done by BIOS or system software, > +but in practice, getting a perfectly synchronized TSC will not be possible > +unless all values are read from the same clock, which generally only is > +possible on single socket systems or those with special hardware > +support. That's not true, single crystal for all sockets is very common as long as you only have a single motherboard. Of course there might be other reasons why the TSC is unsynchronized (e.g. stop count in C-states), but the single clock is not the problem. > +3.4) TSC and C-states > + > +C-states, or idling states of the processor, especially C1E and deeper sleep > +states may be problematic for TSC as well. The TSC may stop advancing in such > +a state, resulting in a TSC which is behind that of other CPUs when execution > +is resumed. Such CPUs must be detected and flagged by the operating system > +based on CPU and chipset identifications. > + > +The TSC in such a case may be corrected by catching it up to a known external > +clocksource. ... This is fixed in recent CPUs ... > + > +3.5) TSC frequency change / P-states > + > +To make things slightly more interesting, some CPUs may change requency. They > +may or may not run the TSC at the same rate, and because the frequency change > +may be staggered or slewed, at some points in time, the TSC rate may not be > +known other than falling within a range of values. In this case, the TSC will > +not be a stable time source, and must be calibrated against a known, stable, > +external clock to be a usable source of time. > + > +Whether the TSC runs at a constant rate or scales with the P-state is model > +dependent and must be determined by inspecting CPUID, chipset or various MSR > +fields. ... In general newer CPUs should not have problems with this anymore > + > +4) Virtualization Problems > + > +Timekeeping is especially problematic for virtualization because a number of > +challenges arise. The most obvious problem is that time is now shared between > +the host and, potentially, a number of virtual machines. This happens > +naturally on X86 systems when SMM mode is used by the BIOS, but not to such a > +degree nor with such frequency. However, the fact that SMM mode may cause The SMM reference here seems at best odd. -Andi -- ak@xxxxxxxxxxxxxxx -- Speaking for myself only. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
