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/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel