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

[Collin Walling]

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

This will be recorded under the host-model as (observable via domcapabilities):

    <mode name='host-model' supported='yes'>
      <model fallback='forbid'>z13.2-base</model>
      <feature policy='require' name='aen'/>
      <feature policy='require' name='aefsi'/>
      <feature policy='require' name='diag318'/>
      ...
      <feature policy='disable' name='csske'/>
      ...

Obviously a hard-coded path is not a desired approach and requires a
constant update whenever newer features are listed for deprecation.
The patch is presented to instead spin up the discussion as to where 
it is appropriate to record these deprecated features (e.g. should these 
be reported under the host-model? or added to the guest CPU definition
prior to start up? etc). There is one issue observed by this change to
the host-model, denoted directly below.

A change in the host-model XML affects the hypervisor-cpu-comparison
command, which uses the libvirt-recorded host-model XML. Issuing 
comparison on a machine that still supports CSSKE (but with it flagged
as disabled in the host-model XML) with an equal or older CPU model 
that does *not* present CSSKE as disabled in the XML will be reported
as incompatible. The response should report "identical" or "superset"
because technically the hardware still supports the feature.

A possible solution is to modify the hypervisor-cpu-comparison command
to query the host-model via expansion to get the proper hypervisor CPU
model as opposed to using libvirt's modified definition.

Secondly, let's discuss the how to report the deprecated features. Namely,
an introduction of a new QEMU QMP response.

This would be a long-term approach that allows a user to query a list of 
deprecated features for a particular architecture. A list will be kept
within QEMU that contains all deprecated CPU features. This allows the
retention of CPU model definitions within QEMU. Libvirt may query this
list and update the host-model definition to disable the features reported
by QEMU.

QEMU QMP Response example:

{ "execute": "query-cpu-model-deprecated-features" }

{ "return": { "props": { "name": "csske", "name": "feat_a", "name": "feat_b" }}}

libvirt pseudo:

if query_deprecated_features is supported
    list = query_deprecated_features()
    for each feat in list
        set feat to disabled for host-model

Then, any new features that are flagged for deprecated in the future may
simply be added to this "deprecated features" list in QEMU alongside a
new CPU definition.

Please let me know your thoughts on these approaches. All input is welcome.

Thanks.

Collin Walling (1):
  qemu: capabilities: disable csske for host cpu

 src/qemu/qemu_capabilities.c               | 10 ++++++++++
 tests/domaincapsdata/qemu_2.11.0.s390x.xml |  1 +
 tests/domaincapsdata/qemu_2.12.0.s390x.xml |  1 +
 tests/domaincapsdata/qemu_2.8.0.s390x.xml  |  1 +
 tests/domaincapsdata/qemu_2.9.0.s390x.xml  |  1 +
 tests/domaincapsdata/qemu_3.0.0.s390x.xml  |  1 +
 tests/domaincapsdata/qemu_4.2.0.s390x.xml  |  1 +
 tests/domaincapsdata/qemu_6.0.0.s390x.xml  |  1 +
 8 files changed, 17 insertions(+)

-- 
2.31.1