On 6/3/24 10:40 AM, Jiri Denemark wrote:
> On Tue, May 07, 2024 at 18:24:20 -0400, Collin Walling wrote:
>> QEMU will soon support reporting an optional array of deprecated
>> features for an expanded CPU model via the query-cpu-model-expansion
>> command. The intended use of this data is to make it easier for a
>> user to define a CPU model with features flagged as deprecated set to
>> disabled, thus rendering the guest migratable to future hardware that
>> will out-right drop support for said features.
>
> So is the list of deprecated features a static list common to all CPU
> models or does it depend on the CPU model? If it's static getting the
> list via another QMP command (in addition to query-cpu-model-expansion)
> would make sense. I would expect the query-cpu-model-expansion to limit
> deprecated features to only those actually used by the expanded CPU
> model, which would make constructing a complete list quite hard.
>
> On the other hand, if the deprecated features depend on a CPU model,
> we'd need a way to list all CPU models and their deprecated features to
> be able to report such info in domain capabilities XML. Ideally without
> having to call query-cpu-model-expansion on every single CPU model.
>
>> Notes
>> =====
>>
>> - In my example below, I am running on a z14.2 machine.
>>
>> - The features that are flagged as deprecated for this model are: bpb, csske, cte, te.
>
> OK, so the deprecated features seem to depend on a specific CPU model.
> Does query-cpu-model-expansion list them even if they are not specified
> in the CPU model we want to expand? If not, we need another interface to
> be able to report this info.
>
The QEMU portion is designed for s390x such that there is a static list
of hardcoded feature bits that are flagged for deprecation. This list
can be updated in follow-up patches as more features need to be flagged.
The query-cpu-model-expansion *response* has been modified to now
include an /optional/ "deprecated props" string array (no additional
parameter is required in the query JSON). This array will be present if
and only if there is data to be reported. If an architecture does not
support reporting deprecated features, or if there are no deprecated
features to report, then array is simply omitted from the response.
The deprecated features are filtered against the full-expansion features
for the particular CPU model. In the example for a z14, we would expect
all four currently deprecated features reported: bpb, csske, cte, and
te, since those features are part of the z14 full expansion. On an
older model, say a z900, you'd only see bpb because the others are not
present in the full-expansion.
>> Ideas
>> =====
>>
>> New Host CPU Model
>> ------------------
>>
>> Create a new CPU model that is a mirror of the host CPU model with deprecated features turned off. Let's call this model "host-recommended". A user may define this model in the guest XML as they would any other CPU model:
>>
>> <cpu mode='host-recommended' check='partial'/>
>>
>> Just as how host-model works, anything defined nested in the <cpu> tag will be ignored.
>>
>> This model could potentially be listed in the domcapabilities output after the host-model:
>>
>> <cpu>
>> <mode name='host-passthrough' supported='yes'>
>> ...
>> </mode>
>> ...
>> <mode name='host-model' supported='yes'>
>> ...
>> </mode>
>> <mode name='host-recommended' supported='yes'>
>> ...
>> <feature policy='disable' name='cte'/>
>> <feature policy='require' name='ais'/>
>> <feature policy='disable' name='bpb'/>
>> <feature policy='require' name='ctop'/>
>> <feature policy='require' name='gs'/>
>> <feature policy='require' name='ppa15'/>
>> <feature policy='require' name='zpci'/>
>> <feature policy='require' name='sea_esop2'/>
>> <feature policy='disable' name='te'/>
>> <feature policy='require' name='cmm'/>
>> <feature policy='disable' name='csske'/>
>> </cpu>
>>
>>
>> New Nested Element Under <cpu>
>> ------------------------------
>>
>> Create a new optional XML element nested under the <cpu> tag that may be used to disable deprecated features. This approach is more explicit compared to creating a new CPU model, and allows the user to disable these features when defining a specific model other than host-model. Here is an example of what the guest's defined XML for the CPU could look like:
>>
>> <cpu mode='host-model' check='partial'>
>> <deprecated_features>off</deprecated_features>
>> </cpu>
>>
>> However, a conflict arises with this approach: parameter priority. It would need to be discussed what the expected behavior should be if a user defines a guest with both a mode to disable deprecated features and any deprecated features listed with the 'require' policy, e.g.:
>>
>> <cpu mode='custom' match='exact' check='partial'>
>> <model fallback='allow'>z13.2-base</model>
>> <!-- which one takes priority? -->
>> <deprecated_features>off</deprecated_features>
>> <feature policy='require' name='csske'/>
>> </cpu>
>>
>> Another conflict is setting this option to "on" would have no effect on the CPU model (I can't think of a reason why someone would want to explicitly enable these features). This may not communicate well to the user.
>
> I think have a separate configuration is better as it does not limit the
> used to just a single CPU model. But a nested element with a text node
> looks strange. An optional attribute for the <cpu> element would be
> better.
>> For host-model the expected behavior would be to either keep or
> drop deprecated features from the CPU definition. When combined with
> custom CPU mode where such feature may be already present I can imagine
> three different options. Either keep deprecated features (that is do
> nothing, just like we do now), drop such features silently, or fail to
> start a domain in case the definition uses a deprecated feature.
I fear the last option may break some things?
>
> We could even create the attribute, but limit it only to host-model,
> which would be mostly equivalent to your "host-recomended" mode, but
> extensible to other modes in the future.
>
I think this is the better approach.
In tandem to your suggestion to add a new attribute to the cpu element,
a quick mock-up of it could look like this:
<cpu mode='host-model' deprecated_features='off'>
and output an error if any other mode is used.
>> To report these features, a <deprecatedProperties> tag could be added to the domcapabilities output using the same format I use in my proposed patch for the qemu capabilities file:
>>
>> <cpu>
>> <mode name='host-passthrough' supported='yes'>
>> ...
>> </mode>
>> ...
>> <mode name='host-model' supported='yes'>
>> ...
>> </mode>
>> <deprecatedProperties>
>> <property name='bpb'/>
>> <property name='te'/>
>> <property name='cte'/>
>> <property name='csske'/>
>> </deprecatedProperties>
>> </cpu>
>
> We should stick with "features" rather than calling them "properties"
> here to avoid confusion. Also this schema would mean the list of
> deprecated features is indeed the same for all CPU models, which does
> not seem to be the case here.
Noted to use "features" instead of "properties".
And you are correct that this makes the assumption that these features
are available for *all* CPU models -- I did not think of this
perspective. This is populated from a query-cpu-model-expansion based
on "host-model".
What would be a better way to report these features in the
domcapabilities response? Perhaps they should only be nested under the
host-model?
...another thought would be to implement a new feature policy
"deprecated" that would allow these XML features to be applied to any
CPU model. This would flag the feature to either be disabled if it's
available for that model, or ignore it otherwise. The validity of the
feature would be checked against the list of deprecated features (to
avoid typos or having a user define an imaginary feature).
Additionally, the feature policy would evaluate to "disabled" for a live
guest XML to alleviate migration issues on machines that do not know
about this new policy.
Consider the following for domcapabilities output:
<cpu>
<mode name='host-passthrough' supported='yes'>
...
</mode>
...
<mode name='host-model' supported='yes'>
...
</mode>
<deprecatedFeatures>
<feature policy='deprecated' name='bpb'/>
<feature policy='deprecated' name='te'/>
<feature policy='deprecated' name='cte'/>
<feature policy='deprecated' name='csske'/>
</deprecatedProperties>
</cpu>
The benefit here is that this would let a user easily copy+paste these
features into their guest XML and not have to consider whether or not
these features are available for the CPU model they wish to use.
Alternatively, the <mode name='host-model' ...> could include the
aforementioned deprecated_features='off' attribute and the nested
features would include the analogous features with policy='disabled'.
This provides the benefit of having a near ready-to-use CPU model XML
with deprecated features that can be provided to the baseline input.
I know I sort of brain-dumped a lot here. Let me know if you'd like for
me to format these ideas into a fashion similar to the initial cover
(maybe an RFC v2) to make discussion threads more readable.
>
> And one more interesting point: what to do with the baseline CPU
> computation which expects to see host-model definitions from all hosts.
> We'd need a way to provide the info about deprecated features to the
> input data for baseline computation. In other words, to the host-model
> definition itself. We could, for example, add a deprecated='yes|no'
> attribute to each feature in the host-model definition. But this won't
> really work when the list of deprecated CPU features depends on a CPU
> model as the baseline may choose a different CPU model than what is used
> by a host-model. So perhaps we may just rely on the host computing the
> baseline CPU to handle deprecated features on the result and document
> this computation should be done on the most up-to-date host so to avoid
> missing features that were deprecated in a later update.
>
The way I imagined this working was to either use the "host-recommended"
CPU model by default (but I believe we are nix'ing that approach), OR
just use the host-model as-is today and rely on the input XML containing
the appropriate list of deprecated features (with policy=disabled). The
input XML containing this CPU model could be extracted from a live guest
that has deprecated features disabled.
> I feel like there's more questions than answers in my reply. Sorry about
> that and the delay.
No worries at all! This is exactly why I wanted to post this as an RFC
and before diving too deeply into the code. Your questions and feedback
are welcome here :)
In summary:
- s/properties/features
- potentially add a new attribute to the cpu element to disable
deprecated features instead of a nested element (Jirka's idea)
- discuss the potential of a new feature policy "deprecated" (Collin's
idea)
- how to handle baseline needs more discussion
To echo part of the discussion from Daniel's feedback, he seems in favor
of providing an explicit indication on the cpu definition that
deprecated features are on|off. I think this works in tandem with a
deprecated_features attribute in the <cpu> element?
>
> Jirka
>
Thanks for the response!
--
Regards,
Collin
