On Fri, Nov 29, 2024 at 09:03:11 +0000, Daniel P. Berrangé wrote:
On Fri, Nov 29, 2024 at 09:50:01AM +0100, Jiri Denemark wrote:
On Fri, Nov 29, 2024 at 12:33:19 +0800, Han Han wrote:
Tested on this branch with qemu-kvm-9.1.0-5.el9.x86_64: # for i in $(/usr/libexec/qemu-kvm -cpu help|grep deprecated -v|awk '/Available CPUs/,/Recognized CPUID flags/'|grep '^ '|awk '{print $1}');do if ! virsh cpu-models x86_64|grep -q $i;then echo $i;fi;done Opteron_G4-v1 Opteron_G5-v1 base host max
Opteron_G4-v1 and Opteron_G5-v1 are not deprecated. Expect to add them to libvirt CPU models as well.
I was not really sure which CPU models are deprecated. According to QEMU none of them is really deprecated (the only CPU model that was ever deprecated was Icelake-Client, which was later dropped completely). The info you use is apparently coming from downstream QEMU, because upstream shows nothing for "qemu-system-x86_64 -cpu help | grep deprecated".
Correct, deprecation of CPUs is a decision RHEL makes downstream, and is not relevant to libvirt's upstream usage.
Libvirt queries QEMU deprecations, so if a user picks a deprecated CPU, their VM will be tainted and show the deprecation message in logs, etc.
I guess we can use the info to say Opteron_G4 and Opteron_G5 should not be ignored by the script, I'm not sure we could use it the other way around for selecting which models are considered deprecated.
We should always honour all CPUs QEMU reports as existing. Deprecated CPUs are still supported for use, it is merely a warning that they /may/ go away in future.
So do you suggest we should not ignore even those ancient lower case CPU models and add their -v1 variants as well? That would seems to me like a lot of churn with no benefit. Although there's no technical reason for ignoring them. Jirka