[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