Lines Matching refs:a
7 As of Xen 4.0, a new config option called tsc_mode may be specified
10 for Xen users and administrators that may need to select a non-default
32 per second per processor, we call this a "high-TSC-frequency"
40 we call this a "TSC-sensitive" app or OS; otherwise it is "TSC-resilient".
46 failure cases. As a result, unless proven otherwise, any app
70 worst-case performance degradation for a specific hardware environment.
84 If tsc_mode is left unspecified (or set to B<tsc_mode=0>), a hybrid
110 an "xl" command can be used by a privileged user of domain0. The
122 The x86 "timestamp counter", or TSC, is a 64-bit register on each
125 at a constant rate even if the processor changes frequency (for example,
128 so it is often used as a foundation for performance monitoring.
131 sometimes used as a random number or a unique sequence identifier,
132 such as to stamp transactions so they can be replayed in a specific
140 apps were ported from a uniprocessor to an SMP environment; as a result,
150 in all power states, even on multi-socket machines, and provide a
160 As a result of TSC's sordid history, two classes of applications use
165 We will refer to apps that might break if running on a TSC-unsafe
167 TSC but use it in a way that monotonicity and frequency invariance
172 a guest OS and all its currently running applications may be invisibly
175 synchronize TSC across a data center or even a pool of machines. As
176 a result, when run in a virtualized environment, rare and obscure
178 TSC-sensitive applications. Worse, if a guest OS moves from, for
179 example, a 3GHz
180 machine to a 1.5GHz machine, attempts by an OS/app to measure time
181 intervals with TSC may without notice be incorrect by a factor of two.
184 TSC register. The rdtscp instruction is a variant of rdtsc on recent
187 privileged software may set a cpuid bit to cause all rdtsc family
192 To provide a "safe" TSC, i.e. to ensure both TSC monotonicity and a
194 explicitly specified by a per-VM configuration option. TSC emulation is
197 the rdtsc instruction at a high frequency (e.g. more than about 10,000 times
202 "TSC-safeness" is not necessary) and highest performance is a
208 will be emulated. Once a virtual machine is save/restored or migrated,
220 might be encountered by a tsc_mode==0 domain after migration occurs,
221 or a tsc_mode==3 domain when it is running on TSC-unsafe hardware.
226 once per second in a guest, and the guest is saved when the TSC is 1000,
234 in a cpuid bit on the most recent x86 processors. If set, TSC invariance
235 ensures that the TSC is "safe", that is it will increment at a constant rate
239 TSC will be safe and continuously incremented at a fixed rate and thus
240 can be used as a system "clocksource".
243 version 2.6.30(?), to select TSC as a system clocksource. Once selected,
245 a virtualized environment, since it is not possible to synchronize TSC
246 across all the machines in a pool or data center, a migration may "break"
247 TSC as a usable clocksource; while time will not go backwards, it may
249 consequences. As a result, Xen can only expose the TSC Invariant bit
250 to a guest OS if it is certain that the domain will never migrate.
253 on a physical machine with "TSC Invariant", Linux 2.6.30+ will safely
259 to Xen, where Xen can "filter" the result. In a PV OS, all cpuid instructions
260 have been replaced by a paravirtualized equivalent of the cpuid instruction
261 ("pvcpuid") and also trap to Xen. But apps in a PV guest that use a
262 cpuid instruction execute it directly, without a trap to Xen. As a result,
269 by guest rdtsc/p increasing in a different frequency than the host
272 If a HVM container in default TSC mode (tsc_mode=0) is created on a host