Re: [libvirt] [RFC] Support for CPUID masking v2

> > 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.