Re: [PATCH v5 5/5] qemu: add default_cpu_deprecated_features configuration option

On Wed, Jul 02, 2025 at 12:05:45PM +0200, Boris Fiuczynski wrote: > On 7/1/25 18:35, Daniel P. Berrangé via Devel wrote: >> On Tue, Jul 01, 2025 at 03:58:02PM +0200, Boris Fiuczynski wrote: >>> On 7/1/25 10:46, Daniel P. Berrangé via Devel wrote: >>>> On Sun, Jun 29, 2025 at 11:19:30PM -0400, Collin Walling wrote: >>>>> From: Boris Fiuczynski <fiuczy(a)linux.ibm.com&gt; >>>>> >>>>> Allow to define the default for deprecated_features when the attribute >>>>> is not set in the cpu defintion of a domain XML. If these features are >>>>> still desired, they may be reenabled via the deprecated_features='on' >>>>> attribute. >>>>> >>>>> Some existing tests utilize this updated behavior, so update the CPU >>>>> features on the corresponding args files. >>>>> >>>>> Signed-off-by: Boris Fiuczynski <fiuczy(a)linux.ibm.com&gt; >>>>> Signed-off-by: Collin Walling <walling(a)linux.ibm.com&gt; >>>>> --- >>>>> src/qemu/libvirtd_qemu.aug | 3 ++ >>>>> src/qemu/qemu.conf.in | 14 ++++++++ >>>>> src/qemu/qemu_conf.c | 33 +++++++++++++++++++ >>>>> src/qemu/qemu_conf.h | 12 +++++++ >>>>> src/qemu/qemu_process.c | 26 ++++++++++++++- >>>>> src/qemu/test_libvirtd_qemu.aug.in | 1 + >>>>> ...deprecated-features-none.s390x-latest.args | 2 +- >>>>> ...default-video-type-s390x.s390x-latest.args | 2 +- >>>>> ...vfio-zpci-ccw-memballoon.s390x-latest.args | 2 +- >>>>> .../launch-security-s390-pv.s390x-latest.args | 2 +- >>>>> ...t-cpu-kvm-ccw-virtio-4.2.s390x-latest.args | 2 +- >>>>> .../s390-defaultconsole.s390x-latest.args | 2 +- >>>>> .../s390-panic.s390x-latest.args | 2 +- >>>>> 13 files changed, 95 insertions(+), 8 deletions(-) >>>>> >>>>> diff --git a/src/qemu/libvirtd_qemu.aug b/src/qemu/libvirtd_qemu.aug >>>>> index e1e479d72c..2b674d258d 100644 >>>>> --- a/src/qemu/libvirtd_qemu.aug >>>>> +++ b/src/qemu/libvirtd_qemu.aug >>>>> @@ -160,6 +160,8 @@ module Libvirtd_qemu = >>>>> let filesystem_entry = str_array_entry "shared_filesystems" >>>>> + let default_cpu_deprecated_features = str_entry "default_cpu_deprecated_features" >>>>> + >>>>> (* Entries that used to exist in the config which are now >>>>> * deleted. We keep on parsing them so we don't break >>>>> * ability to parse old configs after upgrade >>>>> @@ -192,6 +194,7 @@ module Libvirtd_qemu = >>>>> | capability_filters_entry >>>>> | storage_entry >>>>> | filesystem_entry >>>>> + | default_cpu_deprecated_features >>>>> | obsolete_entry >>>>> let comment = [ label "#comment" . del /#[ \t]*/ "# " . store /([^ \t\n][^\n]*)?/ . del /\n/ "\n" ] >>>>> diff --git a/src/qemu/qemu.conf.in b/src/qemu/qemu.conf.in >>>>> index 221bfa8095..368d929f78 100644 >>>>> --- a/src/qemu/qemu.conf.in >>>>> +++ b/src/qemu/qemu.conf.in >>>>> @@ -1100,3 +1100,17 @@ >>>>> # "/path/to/nvram", >>>>> # "/path/to/swtpm" >>>>> #] >>>>> + >>>>> +# If QEMU provides a list of deprecated CPU features it is possible to use >>>>> +# this list for removal of deprecated CPU features during CPU model expansion. >>>>> +# The deprecated_features XML attribute on the XML CPU element in the domain >>>>> +# XML can be used to turn deprecated CPU features 'off' or 'on'. Using the >>>>> +# option default_cpu_deprecated_features allows to define the default behavior >>>>> +# when the attribute deprecated_features is not provided in the domain XML. >>>>> +# >>>>> +# Possible options are: >>>>> +# "off" - (default) deprecated features are removed during CPU model expansion >>>>> +# "on" - deprecated features remain required in the expanded CPU model >>>>> +# "none" - no deprecated_features attribute is added to expanded CPU model >>>>> +# >>>>> +#default_cpu_deprecated_features = "off" >>>> >>>> Having a host level config parameter change the guest ABI seems like a >>>> bad idea to me. IMHO mgmt apps should be updated to use the XML to request >>>> deprecated features are turned off by default. >>> >>> it has been some time but the idea originally is yours. >>> https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/message/M... >> >> Sigh, I'm disagreeing with myself from a year ago :-( >> >> In that comment I was talking about host CPU model, where it is slightly >> acceptable for the expansion to vary over time. What I failed to contemplate >> when I wrote that, was that this applies to all CPU modes, even the named >> CPU models. >> >>> The config parameter gives customers that still make use of the deprecated >>> features in most of there guests the option to bail out of the default >>> switch without having to edit all there guests. Of course they will give up >>> a migrate to a CPU generation which no longer supports the cpu features to >>> work out of the box. >>> The default is switched in this patch to use deprecated_features = "off" >>> which disables all deprecated cpu features without using of the config >>> parameter. >> >> That change in defaults would effectively make the next libvirt version a >> regression compared to all previous versions, as CPU features would be >> disappearing, despite the guest config not changed meanwhile. > > The default is only effective on s390x and if mode="host-model" is set. > So that matches what you talked about. Oh sorry, I misread the patch in this respect. So no objection. Should we also apply to host-passthrough though ? Or is that already being filtered by the kernel ?

With regards, Daniel