[libvirt] [PATCH v5 7/9] tests: check CPU features handling in libxl driver

[Daniel P. Berrangé]

On Fri, Mar 16, 2018 at 08:54:42PM +0100, Marek Marczykowski-Górecki wrote:
> On Fri, Mar 16, 2018 at 05:44:28PM +0000, Daniel P. Berrangé wrote:
> > Since Xen lets you specify raw  "cpuid" register values here, surely
> > this is flexible enough to allow us to support the mode=custom CPU
> > models ?
> > 
> > We would just need to make sure every bit poisition used either
> > 0 or 1, and not 'x', so that we are fully overriding whatever
> > defaults are presented by the hypervisor "host" CPU model. Or is
> > life more complicated than that ?
> 
> This is what v1 of this series had... See discussion there, especially
> message from Jiri:
> https://www.redhat.com/archives/libvir-list/2017-June/msg01304.html
> 
> And this, from... you:
> https://www.redhat.com/archives/libvir-list/2017-June/msg01308.html

Ok, yeah, I remember these discussions now.  What I didn't realize at the
time though, was that the revised patches would end up silently changing
any XML that says mode="custom" + model="Foobar", into mode="host-passthrough"

The core problem we faced in QEMU was that if you take a base named CPU
model and then add/remove 20+ features, some guest OS can get confused.
This is because the combination of features may be unusual, or the
level & xlevel values reported alongside CPUID are unsual for the given
set of features enabled.  The Xen config doesn't provide a way to configure
the level & xlevel values for the CPU, so will potentially hit this same
problem. This is *already* possible though, even with host-passthrough,
since the user can ask for host-passthrough and also disable a whole
bunch of features.

IOW, Jiri is right, but I don't think that neccesarily implies we should
not implement support for mode="custom". I see we have 3 options here
currently

 1. Support mode="custom", using the cpuid config option in libxl
 2. Raise an error when starting a guest with mode="custom"
 3. Translate mode="custom" into mode="host-passthrough" and ignore
    requested named model

So currently situation is that users of libxl libvirt driver may have
deployed guests using arbitrary <cpu> model setup, and that would have
been ignored, giving that a host-passthrough setup.

If we choose option (1), users will have changed semantics for their
existing guests, as instead of getting full host-passthrough, they'll
get a CPU that actually matches the mode=custom their XML has beeen
requesting all along.

If we choose option (2), we'll break existing deployed guests with
mode=custom.

If we choose option (3), users will have preserved semantics for their
existing guests, but we'll never be honouring the actual XML config
the user requested. If we did ever want to properly support mode=custom
in future we're still going doom existing users.


Ideally we would have choosen option (2) from day 1, but that ship
has sailed.

I really dislike, even hate, option (3) because it is explicitly
ignoring a valid XML configuration request and turning it into
something completely different.


So despite the problems / limitations of mode=custom that were previously
raised, I none the less think we should implement mode=custom for the
libxl driver. Then document that its usage is discouraged - for the same
reason that we discourage users from arbitrarily blanking out features
for mode=host-passthrough.

Perhaps in future, we could make mode=custom work more reliably if the
libxl driver provided a way to set the level & xlevel values.

> This is not only about 'x'. But also about setting '1' where hardware
> does not really support given feature. This will also result in "broken"
> CPU.

If we host hardware does not support a given feature bit, then the code
has to make a decision based on the <feature policy=...> setting. ie
"force" would present the feature to the guest, regardless of whether
the host supports ir, while "require" would refuse to start the guest,
and "optional" would silently disable the feature.

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