[libvirt] [PATCH 1/2] XML schema for CPU flags

Jiri Denemark jdenemar at redhat.com
Tue Nov 3 15:40:00 UTC 2009


Firstly, CPU topology and model with optional features have to be
advertised in host capabilities:

    <host>
        <cpu>
            <arch>ARCHITECTURE</arch>
            <features>
                <!-- old-style features are here -->
            </features>
            <model>NAME</model>
            <topology sockets="S" cores="C" threads="T"/>
            <feature>NAME</feature>
        </cpu>
        ...
    </host>

Secondly, drivers which support detailed CPU specification have to advertise
it in guest capabilities:

    <guest>
        ...
        <features>
            <cpu/>
        </features>
    </guest>

And finally, CPU may be configured in domain XML configuration:

<domain>
    ...
    <cpu match="MATCH">
        <model>NAME</model>
        <topology sockets="S" cores="C" threads="T"/>
        <feature policy="POLICY">NAME</feature>
    </cpu>
</domain>

Where MATCH can be one of:
    - 'minimum'     specified CPU is the minimum requested CPU
    - 'exact'       disable all additional features provided by host CPU
    - 'strict'      fail if host CPU doesn't exactly match

POLICY can be one of:
    - 'force'       turn on the feature, even if host doesn't have it
    - 'require'     fail if host doesn't have the feature
    - 'optional'    match host
    - 'disable'     turn off the feature, even if host has it
    - 'forbid'      fail if host has the feature

'force' and 'disable' policies turn on/off the feature regardless of its
availability on host. 'force' is unlikely to be used but its there for
completeness since Xen and VMWare allow it.

'require' and 'forbid' policies prevent a guest from being started on a host
which doesn't/does have the feature. 'forbid' is for cases where you disable
the feature but a guest may still try to access it anyway and you don't want
it to succeed.

'optional' policy sets the feature according to its availability on host.
When a guest is booted on a host that has the feature and then migrated to
another host, the policy changes to 'require' as we can't take the feature
away from a running guest.

Default policy for features provided by host CPU but not specified in domain
configuration is set using match attribute of cpu tag. If 'minimum' match is
requested, additional features will be treated as if they were specified
with 'optional' policy. 'exact' match implies 'disable' policy and 'strict'
match stands for 'forbid' policy.

Signed-off-by: Jiri Denemark <jdenemar at redhat.com>
---
 docs/schemas/capability.rng |   30 ++++++++++++++++++++++++++
 docs/schemas/domain.rng     |   49 +++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 79 insertions(+), 0 deletions(-)

diff --git a/docs/schemas/capability.rng b/docs/schemas/capability.rng
index 3e8944c..faeff4d 100644
--- a/docs/schemas/capability.rng
+++ b/docs/schemas/capability.rng
@@ -25,6 +25,9 @@
 	<optional>
 	  <ref name='cpufeatures'/>
 	</optional>
+        <optional>
+          <ref name='cpuspec'/>
+        </optional>
       </element>
       <optional>
 	<ref name='migration'/>
@@ -67,6 +70,28 @@
     </element>
   </define>
 
+  <define name='cpuspec'>
+    <element name='model'>
+      <text/>
+    </element>
+    <element name='topology'>
+      <attribute name='sockets'>
+        <ref name='uint'/>
+      </attribute>
+      <attribute name='cores'>
+        <ref name='uint'/>
+      </attribute>
+      <attribute name='threads'>
+        <ref name='uint'/>
+      </attribute>
+    </element>
+    <zeroOrMore>
+      <element name='feature'>
+        <text/>
+      </element>
+    </zeroOrMore>
+  </define>
+
   <define name='migration'>
     <element name='migration_features'>
       <optional>
@@ -259,6 +284,11 @@
 	  <empty/>
 	</element>
       </optional>
+      <optional>
+        <element name='cpu'>
+          <empty/>
+        </element>
+      </optional>
     </element>
   </define>
 
diff --git a/docs/schemas/domain.rng b/docs/schemas/domain.rng
index 0a6ab61..eb91572 100644
--- a/docs/schemas/domain.rng
+++ b/docs/schemas/domain.rng
@@ -38,6 +38,9 @@
         <optional>
           <ref name="seclabel"/>
         </optional>
+        <optional>
+          <ref name="cpu"/>
+        </optional>
       </interleave>
     </element>
   </define>
@@ -1193,6 +1196,52 @@
     </optional>
   </define>
   <!--
+      CPU specification
+      -->
+  <define name="cpu">
+    <element name="cpu">
+      <attribute name="match">
+        <choice>
+          <value>minimum</value>
+          <value>exact</value>
+          <value>strict</value>
+        </choice>
+      </attribute>
+      <interleave>
+        <element name="model">
+          <text/>
+        </element>
+        <optional>
+          <element name="topology">
+            <attribute name="sockets">
+              <ref name="uint"/>
+            </attribute>
+            <attribute name="cores">
+              <ref name="uint"/>
+            </attribute>
+            <attribute name="threads">
+              <ref name="uint"/>
+            </attribute>
+          </element>
+        </optional>
+        <zeroOrMore>
+          <element name="feature">
+            <attribute name="policy">
+              <choice>
+                <value>force</value>
+                <value>require</value>
+                <value>optional</value>
+                <value>disable</value>
+                <value>forbid</value>
+              </choice>
+            </attribute>
+            <text/>
+          </element>
+        </zeroOrMore>
+      </interleave>
+    </element>
+  </define>
+  <!--
        Type library
 
        Our unsignedInt doesn't allow a leading '+' in its lexical form
-- 
1.6.5.2




More information about the libvir-list mailing list