=item B<rename-restart>
-rename the domain which terminated, and thenimmediately create a new
+rename the domain which terminated, and then immediately create a new
domain with the same configuration as the original
=item B<preserve>
=item B<KEY=VALUE>
-Posible B<KEY>s are:
+Possible B<KEY>s are:
=over 4
=item B<pci_permissive=BOOLEAN>
(PV only) Changes the default value of 'permissive' for all PCI
-devices for this VM. This can still be overriden on a per-device
+devices for this VM. This can still be overridden on a per-device
basis. This option should be enabled with caution: it gives the guest
much more control over the device, which may have security or
stability implications. It is recommended to enable this option only
=item B<e820_host=BOOLEAN>
Selects whether to expose the host e820 (memory map) to the guest via
-the virtual e820. When this option is false the guest psuedo-physical
+the virtual e820. When this option is false the guest pseudo-physical
address space consists of a single contiguous RAM region. When this
option is specified the virtual e820 instead reflects the host e820
and contains the same PCI holes. The total amount of RAM represented
Exposing the host e820 to the guest gives the guest kernel the
opportunity to set aside the required part of its pseudo-physical
address space in order to provide address space to map passedthrough
-PCI devices. It is guest Operaring System dependant whether this
+PCI devices. It is guest Operating System dependant whether this
option is required, specifically it is required when using a mainline
Linux ("pvops") kernel. This option defaults to true if any PCI
-passthrough devices are configued and false otherwise. If you do not
+passthrough devices are configured and false otherwise. If you do not
configure any passthrough devices at domain creation time but expect
to hotplug devices later then you should set this option. Conversely
if your particular guest kernel does not require this behaviour then
always include these tables. This option is enabled by default and you
should usually omit it but it may be necessary to disable these
firmware tables when using certain older guest Operating
-Systems. These tables have been superceded by newer constructs within
+Systems. These tables have been superseded by newer constructs within
the ACPI tables. (X86 only)
=item B<nx=BOOLEAN>
=item B<opengl=BOOLEAN>
Enable OpenGL acceleration of the SDL display. Only effects machines
-using B<device_model_version="qemu-xen-traditonal"> and only if the
+using B<device_model_version="qemu-xen-traditional"> and only if the
device-model was compiled with OpenGL support. Disabled by default.
=item B<nographic=BOOLEAN>
=back
It is recommended to accept the default value for new guests. If
-you have existing guests then, depeending on the nature of the guest
+you have existing guests then, depending on the nature of the guest
Operating System, you may wish to force them to use the device
model which they were installed with.
=item B<device_model_args=[ "ARG", "ARG", ...]>
-Pass additional arbitrary options on the devide-model command
+Pass additional arbitrary options on the device-model command
line. Each element in the list is passed as an option to the
device-model.
=item B<device_model_args_pv=[ "ARG", "ARG", ...]>
-Pass additional arbitrary options on the devide-model command line for
+Pass additional arbitrary options on the device-model command line for
a PV device model only. Each element in the list is passed as an
option to the device-model.
=item B<device_model_args_hvm=[ "ARG", "ARG", ...]>
-Pass additional arbitrary options on the devide-model command line for
+Pass additional arbitrary options on the device-model command line for
an HVM device model only. Each element in the list is passed as an
option to the device-model.
=item B<autoballoon>
If you specify the amount of memory dom0 has, passing B<dom0_mem> to
-Xen, it is highly rec
comended to disable B<autoballoon>. Edit
+Xen, it is highly rec
ommended to disable B<autoballoon>. Edit
B</etc/xen/xl.conf> and set it to 0.
=item run xl as B<root>
Ratelimit attempts to limit the number of schedules per second. It
sets a minimum amount of time (in microseconds) a VM must run before
-we will allow a higher-prioirty VM to pre-empt it. The default value
+we will allow a higher-priority VM to pre-empt it. The default value
is 1000 microseconds (1ms). Valid range is 100 to 500000 (500ms).
The ratelimit length must be lower than the timeslice length.
=item B<tmem>
-Trascendent Memory.
+Transcendent Memory.
=back
=item B<-F=FILE>, B<--config=FILE>
-Use the given SXP formated configuration script.
+Use the given SXP formatted configuration script.
SXP is the underlying configuration format used by Xen.
SXP configuration scripts can be hand-written or generated
from Python configuration scripts, using the -n
=item B<-F=FILE>, B<--config=FILE>
-Use the given SXP formated configuration script.
+Use the given SXP formatted configuration script.
SXP is the underlying configuration format used by Xen.
SXP configuration scripts can be hand-written or generated
from Python configuration scripts, using the -n
The amount of RAM, in megabytes, to allocate to the domain when it
starts. Allocating insufficient memory for a domain may produce
extremely bizarre behavior. If there isn't enough free memory left on
-the machine to fulfill this request, the domain will fail to start.
+the machine to fulfil this request, the domain will fail to start.
Xen does not support overcommit of memory, so the total memory of all
guests (+ 64 MB needed for Xen) must be less than or equal to the
For example if a new distro uses /etc/bork as its config dir, it's not
sufficient to set CONFIG_LEAF_DIR=bork; one must also add tests for the
-existance of the bork dir in every context where config files are read.
+existence of the bork dir in every context where config files are read.
Kexec and Kdump for Xen
=======================
-This is a breif guide to using Kexec and Kdump in conjunction with Xen.
-This functionaly works at the level of the hypervisor and dom0 kernel.
+This is a brief guide to using Kexec and Kdump in conjunction with Xen.
+This functionally works at the level of the hypervisor and dom0 kernel.
And will thus affect all guests running on a machine.
At this stage it does not work in conjunction with domU kernels.
---------------+--------------------+--------------------
Linux -> Linux | first kernel | second kernel
-If you are kexecing to Xen then you will also need to preapare the second
+If you are kexecing to Xen then you will also need to prepare the second
hypervisor and dom0 kernel that will run after kexec. These may be the same
as the first hypervisor and dom0 kernel that are used before kexec if you
are kexecing from Xen to Xen.
On x86 systems the crash kernel may be either
- A uncompressed vmlinux image if the kernel is not relocatable
- A compressed bzImage or vmlinuz image if the kernel is relocatable
-- Relocatability is crontroled by the CONFIG_RELOCATABLE kernel
+- Relocatability is controlled by the CONFIG_RELOCATABLE kernel
compile configuration parameter. This option may not be available
depending on the kernel version
On ia64
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
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.
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
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
memory = 32
name = "TPMUserDomain0"
vtpm = ['instance=1,backend=0']
-root = "/dev/ram0 cosole=tty ro"
+root = "/dev/ram0 console=tty ro"
vif = ['backend=0']
In the above configuration file the line 'vtpm = ...' provides
The `acpi=noirq` option causes Xen to not parse the ACPI MADT table
looking for IO-APIC entries. This is also not common, and any system
-which requries this option to function should be blacklisted.
+which requires this option to function should be blacklisted.
Additionally, this will not prevent Xen from finding IO-APIC entries
from the MP tables.
readable, some notifications may have been lost).
WATCH_EVENT <epath>|<token>|
- Unsolicited `reply' generated for matching modfication events
+ Unsolicited `reply' generated for matching modification events
as described above. req_id and tx_id are both 0.
<epath> is the event's path, ie the actual path that was
syntax in the configuration file, it consumes the whole rest of the
<diskspec>. Therefore in that case it must come last. This is
permissible even if an empty value for the target was already
- specifed as a positional parameter. This is the only way to
+ specified as a positional parameter. This is the only way to
specify a target string containing metacharacters such as commas
and (in some cases) colons, which would otherwise be
misinterpreted.
* `rtl8139` (default) -- Realtek RTL8139
* `e1000` -- Intel E1000
- * in principal any device supported by your device model
+ * in principle any device supported by your device model
### vifname
To boot the platform into enforcing mode, which means that the policy is
loaded and enforced, append 'flask_enforcing=1' on the grub line.
- This parameter may also be changed through the flask hyercall.
+ This parameter may also be changed through the flask hypercall.
b) flask_enabled
projects / xen.git / commitdiff