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.
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.
With regards,
Daniel
--
|:
https://berrange.com -o-
https://www.flickr.com/photos/dberrange :|
|:
https://libvirt.org -o-
https://fstop138.berrange.com :|
|:
https://entangle-photo.org -o-
https://www.instagram.com/dberrange :|