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.
query-cpu-definitions. This only has one problem: fetching CPU
alias information for multiple machine types required restarting
QEMU for each machine being queried.
This series adds a new `machine` parameter to
query-cpu-definitions, that can be used to query CPU model alias
information for multiple machines without restarting QEMU.
Eduardo Habkost (7):
i386: Use g_autofree at x86_cpu_list_entry()
i386: Add default_version parameter to CPU version functions
i386: Don't use default_cpu_version at "-cpu help"
machine: machine_find_class() function
i386: Remove x86_cpu_set_default_version() function
i386: Don't use default_cpu_version() inside query-cpu-definitions
cpu: Add `machine` parameter to query-cpu-definitions
qapi/machine-target.json | 14 +++-
include/hw/boards.h | 1 +
include/hw/i386/pc.h | 5 +-
target/i386/cpu.h | 6 --
hw/core/machine.c | 16 ++++
hw/i386/pc.c | 3 -
target/arm/helper.c | 4 +-
target/i386/cpu.c | 93 +++++++++++++++-------
target/mips/helper.c | 4 +-
target/ppc/translate_init.inc.c | 4 +-
target/s390x/cpu_models.c | 4 +-
vl.c | 17 +---
tests/acceptance/x86_cpu_model_versions.py | 42 ++++++++++
13 files changed, 154 insertions(+), 59 deletions(-)
--
Thanks,
David / dhildenb
