[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