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

Daniel P. Berrangé berrange at redhat.com
Mon Jul 18 10:22:48 UTC 2022


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.
> 
> 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);

We have a notion of deprecation for CPU models.

I wonder if we should include or omit deprecated CPU models by
default, possibly determined based on a flag ?


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 :|


More information about the libvir-list mailing list