On Wed, Mar 22, 2023 at 05:13:06PM +0100, Boris Fiuczynski wrote: > 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@xxxxxxxxxxxxx> > > > Reviewed-by: Boris Fiuczynski <fiuczy@xxxxxxxxxxxxx> > > > --- > > > 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? The 'cpu-models' commands came first, but its design was rather flawed. It just reported CPU models alone and could not reflect whether they were actually supportable by the hypervisor, and was not extensible to let us fix it. We had to abandon it and switch to the new approach based on domain capabilities which is extensible via the XML. Potentially we could have a virsh hypervisor-cpu-models command that queries the domain capabilities API, rather than adding a new API. 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 :|
