From what I understand:
QEMU - add a "deprecated-features" feature group (more-or-less David's code)
libvirt - recognize a new model name "host-recommended" - query QEMU for host-model + deprecated-features and cache it in caps file (something like <hostRecCpu>) - when guest is defined with "host-recommended", pull <hostRecCPU> from caps when guest is started (similar to how host-model works today)
If this is sufficient, then I can then get to work on this.
My question is what would be the best way to include the deprecated features when calculating a baseline or comparison. Both work with the host-model and may no longer present an accurate result. Say, for example, we baseline a z15 with a gen17 (which will outright not support CSSKE). With today's implementation, this might result in a ridiculously old CPU model which also does not support CSSKE. The ideal response would be a z15 - deprecated features (i.e. host-recommended on a z15), but we'd need a way to flag to QEMU that we want to exclude the deprecated features. Or am I totally wrong about this?
For baselining, it would be reasonable to always disable deprecated features, and to ignore them during the model selection. Should be fairly easy to implement, let me know if you need any pointers.
Thanks David. I'll take a look when I can. I may not be very active this week due to personal items, but intend to knock this out as soon as things settle down on my end.
No need to rush :)
I *assume* that for comparison there is nothing to do.
I think you're right, at least on QEMU's end.
For libvirt, IIRC, comparison will compare the CPU model cached under the hostCPU tag to whatever is in the XML. If comparing, say, a gen17 host (no csske support) with a gen15 XML, the result should come up as "incompatible". To a user, they may think "what the heck, shouldn't old gen run on new gen?"
I assume you mean an expanded host model on a z15 that still shows "csske=true". And it would be correct: the deprecated feature still around on the older machine (indicated in the host model) is not around on the newer machine (not indicated in the host model). So starting a VM with the "host-model" on the old machine cannot be migrated to the new machine. You'd need to start the VM with the new host-TOBENAMED CPU model. Comparing with that would work as expected, as the deprecated features would not be included.
Doesn't the comparison QAPI report which features cause the result of "incompatible"? Would it make sense to amend the libvirt API to report features causing this issue? I believe this is what the --error flag is meant to do, but as far as I know, nothing useful is currently reported.
Most probably it was never implemented on s390x. Makes sense to me.
Something like this (assume we're a gen17 host, and cpu.xml contains a gen15 host-model)
# virsh hypervisor-cpu-compare cpu.xml --error error: Failed to compare hypervisor CPU with cpu.xml error: the CPU is incompatible with host CPU error: host CPU does not support: csske
I guess instead of "host CPU" you'd want to indicate one of the two CPU models provided. Not sure how to differentiate them from the XML. -- Thanks, David / dhildenb