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 :| -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list