> Extend query-cpu-definitions schema to allow it to return two new
> optional fields: "runnable" and "unavailable-features".
> "runnable" will tell if the CPU model can be run in the current
> host. "unavailable-features" will contain a list of CPU
> properties that are preventing the CPU model from running in the
> current host.
>
> Cc: David Hildenbrand <dahi@xxxxxxxxxxxxxxxxxx>
> Cc: Michael Mueller <mimu@xxxxxxxxxxxxxxxxxx>
> Cc: Christian Borntraeger <borntraeger@xxxxxxxxxx>
> Cc: Cornelia Huck <cornelia.huck@xxxxxxxxxx>
> Cc: Jiri Denemark <jdenemar@xxxxxxxxxx>
> Cc: libvir-list@xxxxxxxxxx
> Signed-off-by: Eduardo Habkost <ehabkost@xxxxxxxxxx>
> ---
> qapi-schema.json | 10 +++++++++-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/qapi-schema.json b/qapi-schema.json
> index 54634c4..450e6e7 100644
> --- a/qapi-schema.json
> +++ b/qapi-schema.json
> @@ -2948,11 +2948,19 @@
> # Virtual CPU definition.
> #
> # @name: the name of the CPU definition
> +# @runnable: true if the CPU model is runnable using the current
> +# machine and accelerator. Optional. Since 2.6.
> +# @unavailable-features: List of properties that prevent the CPU
> +# model from running in the current host,
> +# if @runnable is false. Optional.
> +# Since 2.6.
Just FYI, on other architectures (e.g. s390x), other conditions (e.g. cpu
generation) also define if a CPU model is runnable, so the pure availability of
features does not mean that a cpu model is runnable.
We could have runnable=false and unavailable-features being an empty list.
> #
> # Since: 1.2.0
> ##
> { 'struct': 'CpuDefinitionInfo',
> - 'data': { 'name': 'str' } }
> + 'data': { 'name': 'str',
> + '*runnable': 'bool',
> + '*unavailable-features': [ 'str' ] } }
>
> ##
> # @query-cpu-definitions:
David
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list