[libvirt] [RFC] Support for CPUID masking v2

[Daniel P. Berrange]

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.

> > >   Registries are an nightmare by definition, and we should not add
> > > a registry of features in libvirt, nor try to assert any semantic to
> > > those names. So I'm afraid we are good for just sampling/dumping
> > > /proc/cpuinfo and leave the mess to the kernel. The feature list will
> > > grow quite long but that's fine IMHO.
> > 
> > We can actually keep the feature list very short. The key is that we
> > expose a named CPU model which covers 95% of the host PCU features.
> > We then justneed to list CPU features which are not explicitly part
> > of that CPU moidel - which should be a mere handful - certainly less
> > than 10.
> 
>   how do you know those lists and subsets, and how are you gonna keep
> them on the long term. If you take a processor definition from 5 years ago
> and want to make sure none of the new CPU features are not used what's
> the scenario in practice ? Would the application hagve to know the logic
> behind the name we would be defining for the processor type ? Would it
> have to have that knowledge to know that based on that processor type
> then such and such flags are not set ?
>   If we export names which are managed by libvirt, then it becomes
> libvirt responsability to define the matrix of flags names and their
> semantic. And that's really something I'm afraid of.
>   I prefer to delegate to the kernel or virtualization layers (via the
> drivers) to provide those flags and semantics, ultimately they end up
> being maintained either by the chip founders themselves or the
> hypervisors implementors (VMWare).

The key issue here is there is nothing to delegate to in VMWare or Xen
case, since both use the raw CPUID format as their config model - which
is x86 specific so we need to apply a conversion in libvirt. Once we're
doing that, it becomes trivial todo it for exposing the host CPU model
too.

> > >   Somehow we will get the same mess, I assume QEmu interface can provide
> > > that list, right ?
> > >   I'm also wondering if it's not possibly dependant on the machine, I
> > > hope not, i.e. that the emulated CPU features are not also dependent on
> > > the emaulated hardware...
> > 
> > CPU features are really just a artifact of the CPU model.
> 
>   Hopefully ... but my experience with embedded (some time ago admitedly)
> made clear that such or such processor feature may be activated or not
> depending on how they got wired. Even nowadays your CPU may have support
> for things which gets desactivated by the BIOS for example. Not that
> simple IMHO.

The BIOS settings aren't actually toggling the CPU features. If you have
VT/SVM disabled in the BIOS, it'll still be visible in the /proc/cpuinfo
flags data. The BIOS is toggling something else to prevent the feature
being used, even when present.

Regards,
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 :|