Overview ======== 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. Attached to this cover letter is only half of the bigger picture. I've updated the CPU model expansion ABI to parse the new array (if it's available) and store the result in a string list within the qemuMonitorCPUModelInfo struct. I also propose an approach on how to store/retrieve the list of deprecated features in the qemuCaps cache file. All feedback on this patch is certainly welcome. Please note: I do not provide any updates to the respective qemuCaps tests right now. The main goal of this post is to discuss the other half of the design: reporting and enabling a CPU model with deprecated features disabled. I believe the ideal solution involves a way for the user to easily configure their guest with this new data. Two ideas I currently have are outlined below. Other approaches are encouraged. 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. - The discussion regarding the QEMU changes can be found here: https://mail.gnu.org/archive/html/qemu-devel/2024-04/msg04605.html Example of Desired Changes ========================== Here is what I'd like the resulting guest's transient XML to look like for the <cpu> section (I have trimmed the features list for brevity): ... <cpu mode='custom' match='exact' check='partial'> <model fallback='forbid'>z14.2-base</model> <feature policy='require' name='aen'/> <feature policy='require' name='cmmnt'/> <feature policy='require' name='aefsi'/> ... <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> ... 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. 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> Please let me know your thoughts. Once an approach is agreed upon, I will begin development. Collin Walling (1): qemu: monitor: parse deprecated-props from query-cpu-model-expansion response src/qemu/qemu_capabilities.c | 30 ++++++++++++++++++++++++++++++ src/qemu/qemu_monitor.h | 2 ++ src/qemu/qemu_monitor_json.c | 29 ++++++++++++++++++++++++----- 3 files changed, 56 insertions(+), 5 deletions(-) -- 2.43.0 _______________________________________________ Devel mailing list -- devel@xxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxx
