Revisiting the virsh hypervisor-cpu-models/definitions commands

Daniel, Tim, (and others on the upstream list that'd like to chime in) Harken back to a few months ago when I presented a few patches to introduce the virsh hypervisor-cpu-models command. The proposal was turned down, and I was pointed to a patch-set/discussion that Tim introduced almost a year ago today. From what I was able to gather with respect to Tim's patches, it seems like this is not a direction that x86 wants to pursue, but I still see value in these commands for s390 (and perhaps other architectures that may/currently implement CPU models via the hypervisor). I see value in these commands that shine when including the other hypervisor-cpu-* commands: baseline and comparison. What I'd like to accomplish with this conversation: is there an agreement where these virsh commands may be implemented, or at least some guidance on what should be expected for virsh -> hypervisor CPU model commands going forward? I believe that these commands will assist a user in creating a migration-safe CPU model for a guest in a mixed-generation host environment without having to query details from a remote machine. Say I have two machines, a z14 and a z15. If I wanted to know which CPU model I should define my guest with such that I can guarantee a future migration between the two machines, I would need to run domcapabilities on one machine, then transfer it to the other machine to then perform a baseline. I believe this process could be simplified and remove the need to query a remote machine for its CPU definition. With hypervisor-cpu-models, I can get a list of CPU models and their exact names that I'd like to consider in my mixed environment. Let's say I'm on my z15 machine. I want the name of the appropriate z14 model. I run the hypervisor-cpu-models command and I see that the appropriate model for a z14 is a z14.2-base. Now I can feed that string into hypervisor-cpu-definitions and get a proper XML-formatted CPU model. This XML can be fed into hypervisor-cpu-baseline, and produce a CPU model that can run on both a z14 and z15. I was able to compute a migration-safe CPU model for my mixed environment without having to query a remote machine for their host-model. While this is a rudimentary example, future models may become more complex as certain features are removed or deprecated from CPU models (or make it easier for other architectures that have a non-sequential naming scheme). There may be more complex examples that help support this idea, but the main point is that a user can compute a CPU model from a single libvirt instance instead of having to query details from multiple machines. This is achieved by having a set of hypervisor-cpu-* commands to work with. For reference, here are links to the patches and discussions: - Mine I proposed earlier this year (March 2023): https://listman.redhat.com/archives/libvir-list/2023-March/238981.html And here are Tim's: - Patch Set (June 2022): https://listman.redhat.com/archives/libvir-list/2022-June/232626.html - Follow-up Discussion (July 2022): https://listman.redhat.com/archives/libvir-list/2022-July/232891.html Thanks for your time, - Collin