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.
With regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
