Re: [libvirt] [PATCH 2/3] libxl: add support for CPUID features policy
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 :|