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

On Tue, Sep 22, 2009 at 03:52:08PM +0200, Daniel Veillard wrote: > On Tue, Sep 22, 2009 at 02:25:54PM +0100, Daniel P. Berrange wrote: > > No, we should't rely on /proc/cpuinfo because that is Linux specific. > > For Xen and VMWare drivers we want a naming scheme for flags that is > > OS agnostic, in particular so Xen works on Solaris and VMWare works > > nicely on Windows. > > For VMWare I expect the flag list and CPU descriptions to come > from the driver, which can probably extract them from ESX itself. VMWare doesnt expose any named flags / CPU. It just exports the raw CPUID bitmask. So libvirt has to maintain a database of named + flags to convert the VMWare CPUID into something useful. The same situation exists with Xen.

> > That's why I think we should define a naming scheme for all flags in > > libvirt, albeit not hardcoded in the source, or XML schema, but in an > > external data file that can be easily extended when new CPUs come out. > > I don't see how that's gonna scale. Just with the set of processors > suppoorted by QEmu and the number of flags they may each export or not. > Sure an external file would make maintainance way easier, but still... The key is that you don't try to create named CPU model for every possible CPU that Intel/AMD release. You just have a handful of CPU models, and then uses flags to indicate extra features. Thus it becomes tradeoff between the number of CPU models available, vs number of extra flags an app has to list which lets us control the way it scales while still giving flexibility to apps. As a point of reference, QEMU has < 10 named CPU models currently for x86, but with the combination of possible names + flags, it can expose many 100's of different CPUs to the guest.