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

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.