linux-kernel - Re: [Qemu-devel] [RFC PATCH v2 12/15] cpu-model/s390: Extend QMP command query-cpu-definitions

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 17 Feb 2015 11:09:34 -0700
From:	Eric Blake <eblake@...hat.com>
To:	Michael Mueller <mimu@...ux.vnet.ibm.com>, qemu-devel@...gnu.org,
	kvm@...r.kernel.org, linux-s390@...r.kernel.org,
	linux-kernel@...r.kernel.org
CC:	Gleb Natapov <gleb@...nel.org>, Alexander Graf <agraf@...e.de>,
	Christian Borntraeger <borntraeger@...ibm.com>,
	"Jason J. Herne" <jjherne@...ux.vnet.ibm.com>,
	Cornelia Huck <cornelia.huck@...ibm.com>,
	Paolo Bonzini <pbonzini@...hat.com>,
	Andreas Faerber <afaerber@...e.de>,
	Richard Henderson <rth@...ddle.net>
Subject: Re: [Qemu-devel] [RFC PATCH v2 12/15] cpu-model/s390: Extend QMP
 command query-cpu-definitions

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@...ux.vnet.ibm.com>
> ---
>  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


Download attachment "signature.asc" of type "application/pgp-signature" (605 bytes)