On 7/24/25 03:35, Thomas Huth via Devel wrote: > On 30/06/2025 05.19, Collin Walling wrote: >> Changelog >> >> v5 >> - dropped the "none" test in qemuxmlactivetest (see commit for >> details) >> - reordered patches to introduce some tests first, then add >> qemu.conf changes >> >> v4 >> - added qemu.conf option to dictate the default behavior for the >> deprecated_features attribute (Boris) >> - added qemuxmlactivetests (Boris) >> - snuck in missing documentation for deprecated_features in >> formatdomain.rst >> >> v3 >> - added qemu caps check to avoid breaking s390 guests trying to >> default deprecated_features='off' on QEMU versions that >> do not support reporting these features >> >> v2 >> - changed behavior from disabling features on the host model to >> instead flagging the guest CPU to disable deprecated features >> - removed disabling deprecated features on host model in >> virQEMUCapsInitCPUModelS390 >> - added flagging deprecated_feats in qemuProcessUpdateGuestCPU >> - added tests for deprecated_features='on' >> - split virQEMUCapsUpdateCPUDeprecatedFeatures update and >> qemuProcessUpdateGuestCPU changes >> >> The intention of reporting deprecated features and modifying the guest >> CPU model was to alleviate the user from the burden of preparing a guest >> with the necessary amendments to assure migration to newer hardware. >> While that goal was met by way of the "deprecated_features='on|off'" >> attribute, it still adds an extra step that the user must be aware to >> prepare a guest for migration and the errors that stem from an >> unsuccessful migration (due to feature incompatibility) is not always >> clear how to resolve. >> >> These patches make s390 CPU *host models* migration ready from the get-go >> by introducing a qemu.conf option for disabling deprecated features by >> default. They may still be disabled for other model types via the >> respective attribute, or reenabled if desired. The configured behavior >> may be overridden by explicitly providing the attribute within the >> guest XML. > > The patch series sounds reasonable to me, so FWIW: > > Series > Acked-by: Thomas Huth <th...@redhat.com> > > Peter, Michal, could we still get this merged for libvirt 11.6 ? > > Thomas
Thanks for the Ack and helping to move this along. I've posted a patch to the list for NEWS mentioning this features in case this series is accepted in time for 11.6. -- Regards, Collin