[libvirt] [RFC] Support for CPUID masking v2

[Daniel Veillard]

On Tue, Sep 22, 2009 at 03:01:18PM +0100, Daniel P. Berrange wrote:
> 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.

  <sigh/>

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

  Okay, maybe we can keep this maintainable. The alternative is a
very unfriendly and unreliable API. It's just a shame that those
things end up in libvirt, because honnestly it really sounds like
low level logic that not directly tied to virtualization and which
should really come from the system, but since we have remote only
drivers like VMWare, that doesn't exist and we would need this portable
then okay.
  If we go that way, then yes definitely let's make those descriptions
an external file easilly updated by the distro or sysadmin, so that we
don't get upstream update request in 5 years when nobody knows anymore
what a core2duo might have been...

Daniel

-- 
Daniel Veillard      | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
daniel at veillard.com  | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library  http://libvirt.org/