On 02/17/2015 07:24 AM, Michael Mueller wrote:
> This patch implements the QMP command 'query-cpu-definitions' in the S390
> context. The command returns a in terms of machine release date descending
> sorted list of cpu model names in the current host context.
returns a list of cpu model names sorted by descending release dates.
Does guaranteeing the sorting as part of the interface really matter, or
would it be better to just return the list with no documented sorting
(where callers treat it as unsorted)?
> A consumer may
> successfully request each listed cpu model as long for a given accelerator
> this model is runnable.
>
> Thy QMP type AccelCpuModelInfo is introduced and the type CpuDefinitionInfo
> is extended by the optional field 'accelerators'. It contains a list of named
> accelerators and some indication whether the associated cpu model is runnable
> or the default cpu model. The default cpu model is used either no specific cpu
> was requested during QEMU startup or the cpu model with named 'host'.
>
> request:
> {"execute": "query-cpu-definitions"}
>
> answer:
> {"return":
> [{"name":"2964-ga1","accelerators":[{"name":"kvm","runnable":false,"default":false}]},
> {"name":"2828-ga1","accelerators":[{"name":"kvm","runnable":false,"default":false}]},
> {"name":"2827-ga2","accelerators":[{"name":"kvm","runnable":true,"default":true}]},
> {"name":"2827-ga1","accelerators":[{"name":"kvm","runnable":true,"default":false}]},
> {"name":"2818-ga1","accelerators":[{"name":"kvm","runnable":true,"default":false}]},
> ...
> {"name":"2064-ga1","accelerators":[{"runnable":true,"name":"kvm","default":false}]}
> ]
> }
>
Looks okay from an interface perspective.
> Signed-off-by: Michael Mueller <mimu@xxxxxxxxxxxxxxxxxx>
> ---
> qapi-schema.json | 21 +++++++++-
> target-s390x/cpu-models.c | 15 +++++++
> target-s390x/cpu-models.h | 1 +
> target-s390x/cpu.c | 100 +++++++++++++++++++++++++++++++++++++++++++---
> 4 files changed, 130 insertions(+), 7 deletions(-)
>
> diff --git a/qapi-schema.json b/qapi-schema.json
> index 9431fc2..a5d38ae 100644
> --- a/qapi-schema.json
> +++ b/qapi-schema.json
> @@ -2485,16 +2485,35 @@
> 'data': ['qtest', 'tcg', 'kvm', 'xen' ] }
>
> ##
> +# @AccelCpuModelInfo:
> +#
> +# Accelerator specific CPU model data
> +#
> +# @id: the accelerator id
> +#
There is no 'id' field below, did you mean 'name'?
> +# @default: cpu model for 'host'
> +#
> +# @runnable: cpu model can be activated on hosting machine
> +#
> +# Since: 2.3.0
> +#
> +##
> +{ 'type': 'AccelCpuModelInfo',
> + 'data': { 'name': 'AccelId', 'default': 'bool', 'runnable': 'bool' } }
> +
> +##
> # @CpuDefinitionInfo:
> #
> # Virtual CPU definition.
> #
> # @name: the name of the CPU definition
> #
> +# @accelerators: #optional cpu model offered per accelerator (since 2.3.0)
> +#
Must the field be optional, or will we always provide it? Since this is
an output-only field, it is okay for back-compat to make the new field
unconditional.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
