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 ?