On Thu, Jul 24, 2025 at 14:39:02 -0400, Collin Walling wrote: > 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.
Both this series and the NEWS patch are pushed now. Jirka
