qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: David Hildenbrand
Subject: Re: [PATCH 0/7] i386: Add `machine` parameter to query-cpu-definitions
Date: Fri, 25 Oct 2019 10:02:29 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.1

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.

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.

--

Thanks,

David / dhildenb




reply via email to

[Prev in Thread] Current Thread [Next in Thread]