[libvirt] [RFC] Support for CPUID masking v2

[Daniel P. Berrange]

On Tue, Sep 22, 2009 at 05:51:02PM +0200, Jiri Denemark wrote:
> > > 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.

True, but the issue with that is that it is an x86 specific concept.
non-x86 CPU models can't be decomposed into a list of features for
comparison. So I reckon its best to provide some explicit API or
facility in libvirt to compare 2  CPU+feature descriptions for
compatability, so we can hide the x86 specific bits from applications


Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|