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

[Daniel P. Berrangé]

On Mon, Jul 18, 2022 at 11:05:13AM +0100, Daniel P. Berrangé wrote:
> 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 at redhat.com>
> > ---
> >  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

Now I've read forward in the series, I see that there is no
update to virConnectGetDomainCapabilities. I would expect that
to be updated to reflect the alias information, as well as
exposing the same list of CPUs as this 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 :|