On Tue, Nov 03, 2009 at 04:40:00PM +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</feature>
> </cpu>
> ...
> </host>
>
> Secondly, drivers which support detailed CPU specification have to advertise
> it in guest capabilities:
>
> <guest>
> ...
> <features>
> <cpu/>
> </features>
> </guest>
maybe <cpu/> is a bit too generic. <cpuselection/> or something similar
might be a bit better, for example if we want to extend that later to
give there a list of the supported CPU names for example <cpu> would
be handy.
> 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>
I wonder if I don't prefer to have the name in an attribute since
we're going with a single feature at a time.
> 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.
Okay, I think this reflects the consensus from previous discussions
about this. IMHO the nasty part is the set of feature names which
is undefined and unbounded at the moment.
> 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'/>
One thing to note is that the order of the elements here is fixed
they must be present under <cpu> in the exact order given by the schemas
(fine by me).
> @@ -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>
Maybe we want provide a new type excluding 0 here.
by adding at the end
<define name='positiveInteger'>
<data type='positiveInteger'/>
</define>
referencing http://www.w3.org/TR/xmlschema-2/#positiveInteger
since the grammar references
datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes";
similary:
<define name='uint'>
<data type='unsignedInt'/>
</define>
would be nicer than the current definition.
> + </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'>
I would go for <element name='cpuselection'> or similar here
> + <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>
even though we are in an interleave, i.e. the order of elements under
<domain> is not constrained, I would add the optional reference higher,
it's more sensible to see those constraints after description or before
<os>, so I would move that block a little up, even if this doesn't
change the semantic...
<note>Damn I'm pedantic this morning ...</note>
> @@ -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"/>
similar we may want a positiveInteger here with a similar definition
as 0 makes no sense for any of those values.
> + </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/>
sight text is completely unconstrainted... And somehow I think
I would prefer to have
<attribute name="name">
<text/>
</attribute>
and keep feature content empty for the moment, which would allow more
easilly to evolve the format for something more complex if the needs
arise.
> + </element>
> + </zeroOrMore>
> + </interleave>
> + </element>
> + </define>
> + <!--
> Type library
>
> Our unsignedInt doesn't allow a leading '+' in its lexical form
Sounds good to me, a couple of suggestions on the format, naming
and stucture, plus optional improvements on the types used.
Daniel
--
Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
daniel@xxxxxxxxxxxx | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/
--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list