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@xxxxxxxxxx> > --- > 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@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