On 5/26/23 7:35 AM, Daniel P. Berrangé wrote:
On Wed, May 17, 2023 at 05:34:46PM -0400, Collin Walling wrote:
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.
snip
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
BTW, I should say I didn't have a strong objection to the addition of a 'hypervisor-cpu-models' command per-se. My objection was pointing out that virConnectGetHypervisorCPUNames/hypervisor-cpu-models was duplicating info already exposed by virDomainGetCapabilities/domcapabilities.
If you re-propose hypervisor-cpu-models, as a friendly frontend that parses the virDomainGetCapabilities() XML to extract the CPU list, I think that would be justiable.
Admittedly I didn't really explain that well in my feedback at the time.
It's likely I misinterpreted your feedback on my end as well. I appreciate the clarification. I'll get to work on this once some cycles clear up. I'll start with changing the current hypervisor-cpu- models implementation I drew up, and then we can continue the discussion over there for what would make sense for a hypervisor-cpu-definitions command (if it still makes sense to create that one).
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
My objection to that is that it was creating inconsistent way of representing CPU models, because it was dirrecty exposing QEMU terminology bypassing the libvirt mapping, and it wasn't actually possible to use the exposed names.
Thanks for clearing that up. I don't fully understand how the x86 CPU model schemes are set up in libvirt, so it helps to get some exposure / explanation on that area. I understand your comments now.
With regards, Daniel