[libvirt] [RFC] Support for CPUID masking v2

[Jiri Denemark]

> > I'm not 100% sure we should represent CPU features as <feature>NAME</feature>
> > especially because some features are currently advertised as <NAME/>. However,
> > extending XML schema every time a new feature is introduced doesn't look like
> > a good idea at all. The problem is we can't get rid of <NAME/>-style features,
> > which would result in redundancy:
> > 
> >     <features>
> >         <vmx/>
> >         <feature>vmx</feature>
> >     </features>
> > 
> > But I think it's better than changing the schema to add new features.
> 
> I think we need more than just the features in the capabilties XML
> though. eg, if an application wants to configure a guest with a
> CPU model of 'core2duo' then it needs to know whether the host OS
> is at least a 'core2duo' or a superset. 
> 
> In essence I think the host capabilities XML needs to be more closely
> aligned with your proposed guest XML, specifically including a base
> CPU model name, along with any additional features beyond the basic
> set provided by that model.
> 
> Which brings me neatly to the next question
> 
> The host capabilities XML for some random machine says the host CPU is
> a 'core2duo' + 'ssse3' + '3dnow'.
> 
> There is a guest to be run with a XML config requesting 'pentium3' + 
> 'ssse3' as a minimum requirement.
> 
> Now pretend you are not a human who knows pentium3 is a sub-set of 
> core2duo.  How do we know whether it is possible to run the guest
> on that host ?

When I was proposing this, I thought about CPU name to be just a shortcut to a
set of features. That is, you could see if pentium3 is a subset of core2duo by
just translating them into a list of features and comparing them.

Thanks for your comments.

Jirka