From f0088c1bfada88a6b4af6b02aedbe7e115cb994d Mon Sep 17 00:00:00 2001 From: Jiri Denemark Date: Tue, 19 Jan 2010 18:22:45 +0100 Subject: [PATCH] Document elements in capabilities and domain XML Signed-off-by: Jiri Denemark --- docs/formatcaps.html.in | 13 ++++-- docs/formatdomain.html.in | 93 +++++++++++++++++++++++++++++++++++++++ 2 files changed, 103 insertions(+), 3 deletions(-) diff --git a/docs/formatcaps.html.in b/docs/formatcaps.html.in index 36718d93c1..525a3318cb 100644 --- a/docs/formatcaps.html.in +++ b/docs/formatcaps.html.in @@ -21,6 +21,11 @@ BIOS you will see

<features> <vmx/> </features> + <model>core2duo</model> + <topology sockets="1" cores="2" threads="1"/> + <feature name="lahf_lm"/> + <feature name='xtpr'/> + ... </cpu> </host> @@ -48,15 +53,17 @@ BIOS you will see

<loader>/usr/lib/xen/boot/hvmloader</loader> </arch> <features> + <cpuselection/> </features> </guest> ... </capabilities>

The first block (in red) indicates the host hardware capabilities, currently it is limited to the CPU properties but other information may be available, -it shows the CPU architecture, and the features of the chip (the feature -block is similar to what you will find in a Xen fully virtualized domain -description).

+it shows the CPU architecture, topology, model name, and additional features +which are not included in the model but the CPU provides them. Features of the +chip are shown within the feature block (the block is similar to what you will +find in a Xen fully virtualized domain description).

The second block (in blue) indicates the paravirtualization support of the Xen support, you will see the os_type of xen to indicate a paravirtual kernel, then architecture information and potential features.

diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in index af316998d0..ce49f7d493 100644 --- a/docs/formatdomain.html.in +++ b/docs/formatdomain.html.in @@ -201,6 +201,99 @@ CPUs allocated for the guest OS. +

CPU model and topology

+ +

+ Requirements for CPU model, its features and topology can be specified + using the following collection of elements. + Since 0.7.5 +

+ + 
+        ...
+        <cpu match='exact'>
+          <model>core2duo</model>
+          <topology sockets='1' cores='2' threads='1'/>
+          <feature policy='disable' name='lahf_lm'/>
+        </cpu>
+        ...
+ +

+ In case no restrictions need to be put on CPU model and its features, a + simpler cpu element can be used. + Since 0.7.6 +

+ + 
+        ...
+        <cpu>
+          <topology sockets='1' cores='2' threads='1'/>
+        </cpu>
+        ...
+ +
+
cpu
+
The cpu element is the main container for describing + guest CPU requirements. Its match attribute specified how + strictly has the virtual CPU provided to the guest match these + requirements. Since 0.7.6 the + match attribute can be omitted if topology + is the only element within cpu. Possible values for the + match attribute are: + +
+
minimum
+
The specified CPU model and features describes the minimum + requested CPU.
+
exact
+
The virtual CPU provided to the guest will exactly match the + specification
+
strict
+
The guest will not be created unless the host CPU does exactly + match the specification.
+
+
+ +
model
+
The content of the model element specifies CPU model + requested by the guest. The list of available CPU models and their + definition can be found in cpu_map.xml file installed + in libvirt's data directory.
+ +
topology
+
The topology element specifies requested topology of + virtual CPU provided to the guest. Three non-zero values have to be + given for sockets, cores, and + threads: total number of CPU sockets, number of cores per + socket, and number of threads per core, respectively.
+ +
feature
+
The cpu element can contain zero or more + elements used to fine-tune features provided by the + selected CPU model. The list of known feature names can be found in + the same file as CPU models. The meaning of each feature + element depends on its policy attribute, which has to be + set to one of the following values: + +
+
force
+
The virtual CPU will claim the feature is supported regardless + of it being supported by host CPU.
+
require
+
Guest creation will fail unless the feature is supported by host + CPU.
+
optional
+
The feature will be supported by virtual CPU if and only if it + is supported by host CPU.
+
disable
+
The feature will not be supported by virtual CPU.
+
forbid
+
Guest creation will fail if the feature is supported by host + CPU.
+
+
+
+

Lifecycle control