[PATCH RFC 0/1] s390x CPU Model Feature Deprecation

[Christian Borntraeger]

Am 11.03.22 um 10:30 schrieb David Hildenbrand:
> On 11.03.22 05:17, Collin Walling wrote:
>> The s390x architecture has a growing list of features that will no longer
>> be supported on future hardware releases. This introduces an issue with
>> migration such that guests, running on models with these features enabled,
>> will be rejected outright by machines that do not support these features.
>>
>> A current example is the CSSKE feature that has been deprecated for some time.
>> It has been publicly announced that gen15 will be the last release to
>> support this feature, however we have postponed this to gen16a. A possible
>> solution to remedy this would be to create a new QEMU QMP Response that allows
>> users to query for deprecated/unsupported features.
>>
>> This presents two parts of the puzzle: how to report deprecated features to
>> a user (libvirt) and how should libvirt handle this information.
>>
>> First, let's discuss the latter. The patch presented alongside this cover letter
>> attempts to solve the migration issue by hard-coding the CSSKE feature to be
>> disabled for all s390x CPU models. This is done by simply appending the CSSKE
>> feature with the disabled policy to the host-model.
>>
>> libvirt pseudo:
>>
>> if arch is s390x
>>      set CSSKE to disabled for host-model
> 
> That violates host-model semantics and possibly the user intend. There
> would have to be some toggle to manually specify this, for example, a
> new model type or a some magical flag.

What we actually want to do is to disable csske completely from QEMU and
thus from the host-model. Then it would not violate the spec.
But this has all kind of issues (you cannot migrate from older versions
of software and machines) although the hardware still can provide the feature.

The hardware guys promised me to deprecate things two generations earlier
and we usually deprecate things that are not used or where software has a
runtime switch.

 From what I hear from you is that you do not want to modify the host-model
semantics to something more useful but rather define a new thing (e.g. "host-sane") ?

> 
> Gluing this to the "host-model" feels wrong.
> 
> The other concern I have is that deprecated features are a moving
> target, and with a new QEMU version you could suddenly have more
> deprecated features. Hm.
> 
> 
> Maybe you'd want some kind of a host-based-model from QEMU that does
> this automatically? I need more coffee to get creative on a name.
>