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