[libvirt] [PATCH v3 01/13] XML schema for CPU flags

Daniel Veillard veillard at redhat.com
Wed Dec 16 15:15:21 UTC 2009


On Wed, Dec 16, 2009 at 12:03:58AM +0100, Jiri Denemark wrote:
> 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="NAME"/>
>         </cpu>
>         ...
>     </host>
> 
> Secondly, drivers which support detailed CPU specification have to advertise
> it in guest capabilities:
> 
>     <guest>
>         ...
>         <features>
>             <cpuselection/>
>         </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="NAME"/>
>     </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 |   46 +++++++++++++++++++++++++++++++-
>  docs/schemas/domain.rng     |   62 +++++++++++++++++++++++++++++++++++++++++++
>  2 files changed, 107 insertions(+), 1 deletions(-)
> 
> diff --git a/docs/schemas/capability.rng b/docs/schemas/capability.rng
> index 3e8944c..378652e 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,31 @@
>      </element>
>    </define>
>  
> +  <define name='cpuspec'>
> +    <element name='model'>
> +      <text/>
> +    </element>
> +    <element name='topology'>
> +      <attribute name='sockets'>
> +        <ref name='positiveInteger'/>
> +      </attribute>
> +      <attribute name='cores'>
> +        <ref name='positiveInteger'/>
> +      </attribute>
> +      <attribute name='threads'>
> +        <ref name='positiveInteger'/>
> +      </attribute>
> +    </element>
> +    <zeroOrMore>
> +      <element name='feature'>
> +        <attribute name='name'>
> +          <ref name='featureName'/>
> +        </attribute>
> +        <empty/>
> +      </element>
> +    </zeroOrMore>
> +  </define>
> +
>    <define name='migration'>
>      <element name='migration_features'>
>        <optional>
> @@ -259,6 +287,11 @@
>  	  <empty/>
>  	</element>
>        </optional>
> +      <optional>
> +        <element name='cpuselection'>
> +          <empty/>
> +        </element>
> +      </optional>
>      </element>
>    </define>
>  
> @@ -293,8 +326,14 @@
>    </define>
>  
>  
> +  <define name='positiveInteger'>
> +    <data type='positiveInteger'>
> +      <param name="pattern">[0-9]+</param>
> +    </data>
> +  </define>
> +
>    <define name='uint'>
> -    <data type='string'>
> +    <data type='unsignedInt'>
>        <param name="pattern">[0-9]+</param>
>      </data>
>    </define>

  Hum, why do you change this ?
But basically if you use http://www.w3.org/TR/xmlschema-2/#unsignedInt
as the base type then the pattern restriction is superfluous.

> @@ -305,4 +344,9 @@
>      </data>
>    </define>
>  
> +  <define name='featureName'>
> +    <data type='string'>
> +      <param name='pattern'>[a-zA-Z0-9\-_]+</param>
> +    </data>
> +  </define>
>  </grammar>
> diff --git a/docs/schemas/domain.rng b/docs/schemas/domain.rng
[...]
> +  <define name='positiveInteger'>
> +    <data type='positiveInteger'>
> +      <param name="pattern">[0-9]+</param>
> +    </data>
> +  </define>

  Same here, but it's nitpick, it should work as is, ACK,

Daniel

-- 
Daniel Veillard      | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
daniel at veillard.com  | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library  http://libvirt.org/




More information about the libvir-list mailing list