[libvirt] [RFC] Support for CPUID masking v2

[Daniel Veillard]

On Tue, Sep 22, 2009 at 02:25:54PM +0100, Daniel P. Berrange wrote:
> On Tue, Sep 22, 2009 at 02:41:08PM +0200, Daniel Veillard wrote:
> >   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.

  For VMWare I expect the flag list and CPU descriptions to come
from the driver, which can probably extract them from ESX itself.

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

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

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

  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 existing 'acpi' and 'apic' flags are not CPU features - they are
> chipset features, so out of scope for this discussion

  Okay

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

  yes I agree we should unify both formats. The flag list as a single
string isn't fun for applications, granted, something more structured
would be better.

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/