Re: [libvirt PATCH 2/9] libvirt: introduce virConnectGetHypervisorCPUModelNames public API

On Tue, Jun 28, 2022 at 06:09:39PM +0200, Tim Wiederhake wrote: > Create a function to query the hypervisor for its list of known CPU model > names. This is different from virConnectGetCPUModelNames, as this new > function will determine the list of CPU models (and alias names) at > runtime. This is duplicating what we already report in the per-domain level capabilities XML from virConnectGetDomainCapabilities. The original virConnectGetCPUModelNames pre-dated the addition of virConnectGetDomainCapabilities. > Signed-off-by: Tim Wiederhake <twiederh(a)redhat.com&gt; > --- > include/libvirt/libvirt-host.h | 6 ++++ > src/driver-hypervisor.h | 8 +++++ > src/libvirt-host.c | 55 ++++++++++++++++++++++++++++++++++ > src/libvirt_public.syms | 1 + > 4 files changed, 70 insertions(+) > > diff --git a/include/libvirt/libvirt-host.h b/include/libvirt/libvirt-host.h > index 3112f2b676..5aaa001adb 100644 > --- a/include/libvirt/libvirt-host.h > +++ b/include/libvirt/libvirt-host.h > @@ -962,6 +962,12 @@ int virConnectGetCPUModelNames(virConnectPtr conn, > char ***models, > unsigned int flags); > > +int virConnectGetHypervisorCPUModelNames(virConnectPtr conn, > + const char *arch, > + char ***names, > + char ***aliases, > + unsigned int flags); For virConnectCompareHypervisorCPU, virConnectBaselineHypervisorCPU, and virConnectGetDomainCapabilities, we take more than just the 'arch' value: const char *emulator, const char *arch, const char *machine, const char *virttype, because we need all 4 of those pieces of information to accurately determine what qemu-system-XXXX binary we're going to select. If we do still want to add virConnectGetHypervisorCPUModelNames despite having the info on virConnectGetDomainCapabilities, we should take the full set of params. I guess adding the new API isn't too costly