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
