aboutsummaryrefslogtreecommitdiffstats
path: root/docs/misc/tscmode.txt
diff options
context:
space:
mode:
authorTim Deegan <tim@xen.org>2012-06-28 16:57:26 +0100
committerTim Deegan <tim@xen.org>2012-06-28 16:57:26 +0100
commit8c77bfea391cde0ae46c37d77d407c3dd9951583 (patch)
tree233822e192d46210713d3ac0575ac2ce4d9c91a9 /docs/misc/tscmode.txt
parentcc6ba55e078df848b5fccc366f19388549f128c5 (diff)
downloadxen-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.txt10
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