Revisiting the virsh hypervisor-cpu-models/definitions commands

[Collin Walling]

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