On 25.10.19 15:38, Eduardo Habkost wrote:
CCing danpb, libvir-list, mskrivanek.
On Fri, Oct 25, 2019 at 09:17:46AM +0200, 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'm not sure yet if there are the x86-specific goals and
constraints that would make it difficult to follow the same
approach followed by s390x. I have the impression we do,
but I need to think more carefully about it.
Let's discuss that during KVM Forum?
I won't be attending KVM Forum this year, but Christian should be around.
The two main goals of versioned CPU models in x86 are:
1) Decoupling CPU model updates from machine-types (users should be
able to update a CPU model definition without changing machine
type).
2) Letting management software automate CPU model updates.
Normally this is necessary when bare metal microcode or
software updates add/remove features from CPUs. Sometimes the
Virtual CPU model update needs to be performed before the host
updates are applied (if features are being removed)
We have 2) on s390x after a QEMU machine update. You need a QEMU update
usually either way to support the new CPU feature. But I can see how
decoupling the CPU model definition from the machine makes this easier.
It does introduce complexity. It applies only when running older QEMU
machines, or if we have to update a CPU model before we get a new QEMU
machine.
But we do have versioned CPU models already, so the discussion is
already over :)
The main constraint that makes it difficult to address the above
without a new API is:
A) Every CPU model in x86 except "host" is already expected to
be migration-safe (I don't know how this compares to s390x).
I would describe that not a bug but a feature :) It does come with the
price that only using the newest QEMU machine results in the newest CPU
model, that part I understand.
--
Thanks,
David / dhildenb
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
