[libvirt] [PATCH 2/3] libxl: add support for CPUID features policy

[Daniel P. Berrange]

On Thu, Jun 29, 2017 at 10:39:26AM +0200, Marek Marczykowski-Górecki wrote:
> On Thu, Jun 29, 2017 at 10:04:42AM +0200, Jiri Denemark wrote:
> > On Thu, Jun 29, 2017 at 03:11:42 +0200, Marek Marczykowski-Górecki wrote:
> > > Set CPU features in appropriate libxl structure.
> > > Use old "xend" syntax, because it allow control over any bit and libvirt
> > > already have API for translating features to appropriate cpuid bits. And
> > > also features naming in libxl do not match the one of libvirt in
> > > multiple cases.
> > 
> > How does the new syntax look like? 
> 
> "host,tm=0,sse3=0"
> 
> > And would it be actually better? 
> 
> Maybe? But the new syntax use different names for many features (like
> pni vs sse3, or sep vs sysenter), so it would require some ugly
> translation table...

That's not particularly difficult or ugly. Currently virCPUFeatureDEf
stores the feature as a string, but we could easily define an enum
for the feature names, and then store them as an int. We already have
support for doing trivial enum -> string conversions. 

> What I would really like here, is to get list of bits specified with
> <feature ...>, _without_ those defined by <model>. And maybe even
> without requiring <model> to be set at all.

That would take operation of the Xen driver in a very different direction
to the QEMU driver, which I feels is not desirable for applications using
libvirt.

> Another misleading thing about interpreting <model> here is, it doesn't
> mask out features not really present in that CPU. So, you get a CPU
> based on <model> but with many additional features.
> 
> > The
> > problem with setting individual CPUID bits is very fragile. That's
> > mostly what we naively started to do in qemu driver and we're fighting
> > with it since then. It's way too easy to create a virtual CPU which a
> > guest OS will crash on.
> 
> Well, IMHO if you modify things like CPUID you should really know what
> you are doing...

The problem is that we've seen real world evidence that apps & users don't
know what they're doing here. Sooo many bug reports where guests have been
given arbitrary features, causing the guest OS and/or apps to randomly
crash due to wierdly unexpected combinations of features. 

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|