Re: [PATCH v1 3/4] virsh: Introduce new hypervisor-cpu-models command

On 3/22/23 4:53 PM, Daniel P. Berrangé wrote: > On Wed, Mar 22, 2023 at 11:39:17AM -0400, Collin Walling wrote: > > This command is a virsh wrapper for virConnectGetHypervisorCPUNames. > > > > Signed-off-by: Collin Walling <walling(a)linux.ibm.com&gt; > > Reviewed-by: Boris Fiuczynski <fiuczy(a)linux.ibm.com&gt; > > --- > > docs/manpages/virsh.rst | 20 ++++++++++++ > > tools/virsh-host.c | 70 +++++++++++++++++++++++++++++++++++++++++ > > 2 files changed, 90 insertions(+) > > > > diff --git a/docs/manpages/virsh.rst b/docs/manpages/virsh.rst > > index 26c328d390..c156e60d6e 100644 > > --- a/docs/manpages/virsh.rst > > +++ b/docs/manpages/virsh.rst > > @@ -1004,6 +1004,26 @@ listed in the XML description. If *--migratable* is specified, features that > > block migration will not be included in the resulting CPU. > > +hypervisor-cpu-models > > +--------------------- > > + > > +**Syntax:** > > + > > +:: > > + > > + hypervisor-cpu-models [virttype] [emulator] [arch] [machine] > > + > > +Print the list of CPU models known by the hypervisor for the specified architecture. > > +It is not guaranteed that a listed CPU will run on the host. To determine CPU > > +model compatibility with the host, see ``virsh hypervisor-cpu-baseline`` and > > +``virsh hypervisor-cpu-compare``. > > + > > +The *virttype* option specifies the virtualization type (usable in the 'type' > > +attribute of the <domain> top level element from the domain XML). *emulator* > > +specifies the path to the emulator, *arch* specifies the CPU architecture, and > > +*machine* specifies the machine type. > > This is redundant IMHO, as domcapabilities already reports, along with > info about the usability. > > $ virsh domcapabilities | xmllint -xpath "//cpu/mode[@name='custom']/model[@usable='yes']/text()" - | sort > 486 > Broadwell-noTSX > Broadwell-noTSX-IBRS > Conroe > core2duo > coreduo > Haswell-noTSX > Haswell-noTSX-IBRS > IvyBridge > IvyBridge-IBRS > kvm32 > kvm64 > n270 > Nehalem > Nehalem-IBRS > Opteron_G1 > Opteron_G2 > Penryn > pentium > pentium2 > pentium3 > qemu32 > qemu64 > SandyBridge > SandyBridge-IBRS > Skylake-Client-noTSX-IBRS > Westmere > Westmere-IBRS > > > Admittedly xpath is hairy, but the same info could be got with grep+awk > if desired. Isn't the redundancy already existing with "virsh cpu-models"? If users have to use the hypervisor-cpu-* calls and they have used the cpu-* calls before shouldn't the usability be about the same?