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

Reply via email to