Re: [PATCH 0/7] i386: Add `machine` parameter to query-cpu-definitions

[Eduardo Habkost]

CCing mskrivanek, danpb, libvir-list.

On Fri, Oct 25, 2019 at 10:02:29AM +0200, David Hildenbrand wrote:
> On 25.10.19 09:55, Christian Borntraeger wrote:
> > 
> > 
> > On 25.10.19 09:17, David Hildenbrand wrote:
> > > On 25.10.19 04:25, Eduardo Habkost wrote:
> > > > We had introduced versioned CPU models in QEMU 4.1, including a
> > > > method for querying for CPU model versions using
> > > 
> > > Interesting, I was not aware of that.
> > > 
> > > On s390x, we somewhat have versioned CPU models, but we decided against 
> > > giving them explicit names (e.g., z13-v1 or z13-4.1.0), because it didn't 
> > > really seem to be necessary. (and we often implement/add features for 
> > > older CPU models, there is a lot of fluctuation) Actually, you would have 
> > > had to add "z13-z/VM-x.x.x" or "z13-LPAR-x.x.x" or "z13-KVM-x.x.x" to 
> > > model the features you actually see in all the different virtual 
> > > environments ("what a CPU looks like"). Not to talk about QEMU versions 
> > > in addition to that. So we decided to always model what you would see 
> > > under LPAR and are able to specify for a KVM guest. So you can use "z13" 
> > > in an up-to-date LPAR environment, but not in a z/VM environment (you 
> > > would have to disable features).
> > > 
> > > Each (!base) CPU model has a specific feature set per machine. Libvirt 
> > > uses query-cpu-model-expansion() to convert this model+machine to a 
> > > machine-independent representation. That representation is sufficient for 
> > > all use cases we were aware of (esp. "virsh domcapabilities", the host 
> > > CPU model, migration).
> > > 
> > > While s390x has versioned CPU models, we have no explicit way of 
> > > specifying them for older machines, besides going over 
> > > query-cpu-model-expansion and using expanded "base model + features".
> > > 
> > > I can see that this might make sense on x86-64, where you only have maybe 
> > > 3 versions of a CPU (e.g., the one Intel messed up first - Haswell, the 
> > > one Intel messed up next - Haswell-noTSX, and the one that Intel 
> > > eventually did right - Haswell-noTSX-IBRS) and you might want to specify 
> > > "Haswell" vs. "Haswell-IBRS" vs. "Haswell-noTSX-IBRS". But actually, you 
> > > will always want to go for "Haswell-noTSX-IBRS", because you can expect 
> > > to run in updated environments if I am not wrong, everything else are 
> > > corner cases.
> > > 
> > > Of course, versioned CPU model are neat to avoid "base model + list of 
> > > features", but at least for expanding the host model on s390x, it is not 
> > > really helpful. When migrating, the model expansion does the trick.
> > > 
> > > I haven't looked into details of "how to specify or model versions". 
> > > Maybe IBM wants to look into creating versions for all the old models we 
> > > had. But again, not sure if that is of any help for s390x. CCing IBM.
> > 
> > I agree that this does not look very helpful.
> > Especially as several things depend on the kernel version a QEMU version is
> > not sufficient to be guarantee construction success.
> > So we would need something like z14-qemu4.0-kernel-5.2-suse-flavour-onLPAR
> > 
> > Instead we do check if we can construct an equivalent model on the 
> > migration target.
> > And that model is precise. We do even have versions.
> > Right now with QEMU on s390  our models are versioned in a way that we 
> > fence of
> > facilities for old machine versions.
> > 
> > For example
> > -machine s390-virtio-ccw-3.1 -cpu z14 will not have the multiple epoch 
> > facility
> > and
> > -machine s390-virtio-ccw-4.0 -cpu z14 will have the multiple epoch facility.
> > As migration does always require the tuple of machine and cpu this is save. 
> > I fail
> > to see what the benefit of an explicit z14-3.1 would be.
> > 
> 
> AFAIKS the only real benefit of versioned CPU models is that you can add new
> CPU model versions without new QEMU version.
> 
> Then you can specify "-cpu z13-vX" or "-cpu z13 -cpuv X" (no idea how
> versioned CPU model were implemented) on any QEMU machine. Which is the same
> as telling your customer "please use z13,featX=on" in case you have a good
> reason to not use the host model (along with baselining) but use an explicit
> model.

Exactly.  oVirt, specifically, don't use host-model.

> 
> If you can change the default model of QEMU machines, you can automate this
> process. I am pretty sure this is a corner case, though (e.g., IBRS).
> Usually you have a new QEMU machine and can simply enable the new feature
> from that point on.

When -noTSX happened, we thought it was a corner case.  Then we
had -IBRS & -IBPB.  Then we had SSBD (with no new CPU models).
Then we had MD_CLEAR (with no new CPU models).  It's now very
easy to get an insecure VM created if you are not using
host-model.

-- 
Eduardo