[libvirt] [RFC] Support for CPUID masking v2

[Daniel P. Berrange]

On Tue, Sep 22, 2009 at 02:41:08PM +0200, Daniel Veillard 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>
> 
>   I'm not afraid of that, it's not ideal but since those are
>   virtualization related features having them separated sounds fine.
> We just can't grow the schemas and parsing code to accomodate a
> different element for each different name.
> 
>   IMHO the worst is that the definition of the names.
> First there is gonna be a bunch of them and second their name if you
> rely just on the procinfo output may not be sufficient in the absolute.


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.

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.



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

> > Secondly, drivers which support detailed CPU specification have to advertise
> > it in guest capabilities. In case <features> are meant to be hypervisor
> > features, than it could look like:
> > 
> >     <guest>
> >         ...
> >         <features>
> >             <cpu/>
> >         </features>
> >     </guest>
> 
>   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.

The existing 'acpi' and 'apic' flags are not CPU features - they are
chipset features, so out of scope for this discussion

> > But if they are meant to be CPU features, we need to come up with something
> > else:
> > 
> >     <guest>
> >         ...
> >         <cpu_selection/>
> >     </guest>
> 
>   Something like
>       <guest>
>          <cpu model="foo">
>            <features>fpu vme de pse tsc msr pae mce cx8 apic</features>
>          </cpu>
>          <cpu model="bar">
>            <features>fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca</features>
>          </cpu>
>      </guest>
> 
> hoping it doesn't go per machine !

Exposing flags as a big string like this is really not nice for applications.
Having different representations for capabilities XML description of a CPU
vs the guest XML description of a CPU is also undesirable, thus I think thta
the capabilities XML should essentially follow whatever schema we decide to
use for the guest XML


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