Document <cpu> elements in capabilities and domain XML

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
This commit is contained in:
Jiri Denemark 2010-01-19 18:22:45 +01:00
parent d392f4db9d
commit f0088c1bfa
2 changed files with 103 additions and 3 deletions

View File

@ -21,6 +21,11 @@ BIOS you will see</p>
&lt;features&gt;
&lt;vmx/&gt;
&lt;/features&gt;
&lt;model&gt;core2duo&lt;/model&gt;
&lt;topology sockets="1" cores="2" threads="1"/&gt;
&lt;feature name="lahf_lm"/&gt;
&lt;feature name='xtpr'/&gt;
...
&lt;/cpu&gt;
&lt;/host&gt;</span>
@ -48,15 +53,17 @@ BIOS you will see</p>
&lt;loader&gt;/usr/lib/xen/boot/hvmloader&lt;/loader&gt;
&lt;/arch&gt;
&lt;features&gt;
&lt;cpuselection/&gt;
&lt;/features&gt;
&lt;/guest&gt;</span>
...
&lt;/capabilities&gt;</pre>
<p>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).</p>
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).</p>
<p>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.</p>

View File

@ -201,6 +201,99 @@
CPUs allocated for the guest OS.</dd>
</dl>
<h3><a name="elementsCPU">CPU model and topology</a></h3>
<p>
Requirements for CPU model, its features and topology can be specified
using the following collection of elements.
<span class="since">Since 0.7.5</span>
</p>
<pre>
...
&lt;cpu match='exact'&gt;
&lt;model&gt;core2duo&lt;/model&gt;
&lt;topology sockets='1' cores='2' threads='1'/&gt;
&lt;feature policy='disable' name='lahf_lm'/&gt;
&lt;/cpu&gt;
...</pre>
<p>
In case no restrictions need to be put on CPU model and its features, a
simpler <code>cpu</code> element can be used.
<span class="since">Since 0.7.6</span>
</p>
<pre>
...
&lt;cpu&gt;
&lt;topology sockets='1' cores='2' threads='1'/&gt;
&lt;/cpu&gt;
...</pre>
<dl>
<dt><code>cpu</code></dt>
<dd>The <code>cpu</code> element is the main container for describing
guest CPU requirements. Its <code>match</code> attribute specified how
strictly has the virtual CPU provided to the guest match these
requirements. <span class="since">Since 0.7.6</span> the
<code>match</code> attribute can be omitted if <code>topology</code>
is the only element within <code>cpu</code>. Possible values for the
<code>match</code> attribute are:
<dl>
<dt><code>minimum</code></dt>
<dd>The specified CPU model and features describes the minimum
requested CPU.</dd>
<dt><code>exact</code></dt>
<dd>The virtual CPU provided to the guest will exactly match the
specification</dd>
<dt><code>strict</code></dt>
<dd>The guest will not be created unless the host CPU does exactly
match the specification.</dd>
</dl>
</dd>
<dt><code>model</code></dt>
<dd>The content of the <code>model</code> element specifies CPU model
requested by the guest. The list of available CPU models and their
definition can be found in <code>cpu_map.xml</code> file installed
in libvirt's data directory.</dd>
<dt><code>topology</code></dt>
<dd>The <code>topology</code> element specifies requested topology of
virtual CPU provided to the guest. Three non-zero values have to be
given for <code>sockets</code>, <code>cores</code>, and
<code>threads</code>: total number of CPU sockets, number of cores per
socket, and number of threads per core, respectively.</dd>
<dt><code>feature</code></dt>
<dd>The <code>cpu</code> element can contain zero or more
<code>elements</code> 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 <code>feature</code>
element depends on its <code>policy</code> attribute, which has to be
set to one of the following values:
<dl>
<dt><code>force</code></dt>
<dd>The virtual CPU will claim the feature is supported regardless
of it being supported by host CPU.</dd>
<dt><code>require</code></dt>
<dd>Guest creation will fail unless the feature is supported by host
CPU.</dd>
<dt><code>optional</code></dt>
<dd>The feature will be supported by virtual CPU if and only if it
is supported by host CPU.</dd>
<dt><code>disable</code></dt>
<dd>The feature will not be supported by virtual CPU.</dd>
<dt><code>forbid</code></dt>
<dd>Guest creation will fail if the feature is supported by host
CPU.</dd>
</dl>
</dd>
</dl>
<h3><a name="elementsLifecycle">Lifecycle control</a></h3>
<p>