diff options
author | Tim Deegan <tim@xen.org> | 2012-06-28 16:57:26 +0100 |
---|---|---|
committer | Tim Deegan <tim@xen.org> | 2012-06-28 16:57:26 +0100 |
commit | 8c77bfea391cde0ae46c37d77d407c3dd9951583 (patch) | |
tree | 233822e192d46210713d3ac0575ac2ce4d9c91a9 /docs/misc/tscmode.txt | |
parent | cc6ba55e078df848b5fccc366f19388549f128c5 (diff) | |
download | xen-8c77bfea391cde0ae46c37d77d407c3dd9951583.tar.gz xen-8c77bfea391cde0ae46c37d77d407c3dd9951583.tar.bz2 xen-8c77bfea391cde0ae46c37d77d407c3dd9951583.zip |
docs: various typos
Signed-off-by: Tim Deegan <tim@xen.org>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson.citrix.com>
Diffstat (limited to 'docs/misc/tscmode.txt')
-rw-r--r-- | docs/misc/tscmode.txt | 10 |
1 files changed, 5 insertions, 5 deletions
diff --git a/docs/misc/tscmode.txt b/docs/misc/tscmode.txt index 4f4d8f6132..e8c84e8004 100644 --- a/docs/misc/tscmode.txt +++ b/docs/misc/tscmode.txt @@ -121,7 +121,7 @@ may not remain) synchronized as "TSC-unsafe". As a result of TSC's sordid history, two classes of applications use TSC: old applications designed for single processors, and the most recent -enteprise applications which require high-frequency high-precision +enterprise applications which require high-frequency high-precision timestamping. We will refer to apps that might break if running on a TSC-unsafe @@ -151,13 +151,13 @@ instructions to trap. This trap can be detected by Xen, which can then transparently "emulate" the results of the rdtsc instruction and return control to the code following the rdtsc instruction. -To provide a "safe" TSC, i.e. to ensure both TSC monontonicity and a +To provide a "safe" TSC, i.e. to ensure both TSC monotonicity and a fixed rate, Xen provides rdtsc emulation whenever necessary or when explicitly specified by a per-VM configuration option. TSC emulation is relatively slow -- roughly 15-20 times slower than the rdtsc instruction when executed natively. However, except when an OS or application uses the rdtsc instruction at a high frequency (e.g. more than about 10,000 times -per second per processor), this performance degradation is not noticable +per second per processor), this performance degradation is not noticeable (i.e. <0.3%). And, TSC emulation is nearly always faster than OS-provided alternatives (e.g. Linux's gettimeofday). For environments where it is certain that all apps are TSC-resilient (e.g. @@ -196,7 +196,7 @@ all apps running in this virtual machine. This means that all apps must either be TSC-resilient or pvrdtscp-modified. Second, highest performance is only obtained on TSC-safe machines that support the rdtscp instruction; when running on older machines, -rdtscp is emulated and thus slower. For more information on PVRTSCP, +rdtscp is emulated and thus slower. For more information on PVRDTSCP, see below. Finally, tsc_mode==1 always enables TSC emulation, regardless of @@ -243,7 +243,7 @@ saved, restore this domain will fail. There is another cpuid-related complication: The x86 cpuid instruction is non-privileged. HVM domains are configured to always trap this instruction to Xen, where Xen can "filter" the result. In a PV OS, all cpuid instructions -have been replaced by a parvirtualized equivalent of the cpuid instruction +have been replaced by a paravirtualized equivalent of the cpuid instruction ("pvcpuid") and also trap to Xen. But apps in a PV guest that use a cpuid instruction execute it directly, without a trap to Xen. As a result, an app may directly examine the physical TSC Invariant cpuid bit and make |