qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Eric Blake <eblake@redhat.com>
To: Michael Mueller <mimu@linux.vnet.ibm.com>,
	qemu-devel@nongnu.org, kvm@vger.kernel.org,
	linux-s390@vger.kernel.org, linux-kernel@vger.kernel.org
Cc: Gleb Natapov <gleb@kernel.org>, Alexander Graf <agraf@suse.de>,
	Christian Borntraeger <borntraeger@de.ibm.com>,
	"Jason J. Herne" <jjherne@linux.vnet.ibm.com>,
	Cornelia Huck <cornelia.huck@de.ibm.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Andreas Faerber <afaerber@suse.de>,
	Richard Henderson <rth@twiddle.net>
Subject: Re: [Qemu-devel] [RFC PATCH v2 12/15] cpu-model/s390: Extend QMP command query-cpu-definitions
Date: Tue, 17 Feb 2015 11:09:34 -0700	[thread overview]
Message-ID: <54E383DE.5060902@redhat.com> (raw)
In-Reply-To: <1424183053-4310-13-git-send-email-mimu@linux.vnet.ibm.com>

[-- Attachment #1: Type: text/plain, Size: 3258 bytes --]

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@linux.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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]

  reply	other threads:[~2015-02-17 18:10 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-17 14:23 [Qemu-devel] [RFC PATCH v2 00/15] QEMU: s390: cpu model implementation Michael Mueller
2015-02-17 14:23 ` [Qemu-devel] [RFC PATCH v2 01/15] cpu-model: Introduce probe mode for machine none Michael Mueller
2015-02-17 14:24 ` [Qemu-devel] [RFC PATCH v2 02/15] cpu-model: Introduce option --probe to switch into probe mode Michael Mueller
2015-02-17 19:16   ` Eric Blake
2015-02-18  9:08     ` Michael Mueller
2015-02-17 14:24 ` [Qemu-devel] [RFC PATCH v2 03/15] cpu-model: Introduce stub routine cpu_desc_avail Michael Mueller
2015-02-17 14:24 ` [Qemu-devel] [RFC PATCH v2 04/15] cpu-model/s390: Introduce S390 CPU models Michael Mueller
2015-02-20 13:54   ` Alexander Graf
2015-02-20 15:00     ` Michael Mueller
2015-02-20 15:22       ` Alexander Graf
2015-02-20 15:49         ` Michael Mueller
2015-02-20 16:57           ` Alexander Graf
2015-02-20 17:37             ` Michael Mueller
2015-02-20 17:50               ` Alexander Graf
2015-02-20 19:43                 ` Michael Mueller
2015-02-20 19:55                   ` Alexander Graf
2015-02-23 12:56         ` Christian Borntraeger
2015-02-23 13:27           ` Christian Borntraeger
2015-02-20 13:55   ` Alexander Graf
2015-02-20 15:02     ` Michael Mueller
2015-02-17 14:24 ` [Qemu-devel] [RFC PATCH v2 05/15] cpu-model/s390: Introduce S390 CPU facilities Michael Mueller
2015-02-17 14:24 ` [Qemu-devel] [RFC PATCH v2 06/15] cpu-model/s390: Define cpu model specific facility lists Michael Mueller
2015-02-17 14:24 ` [Qemu-devel] [RFC PATCH v2 07/15] cpu-model/s390: Add cpu model alias definition routines Michael Mueller
2015-02-17 14:24 ` [Qemu-devel] [RFC PATCH v2 08/15] cpu-model/s390: Update linux-headers/asm-s390/kvm.h Michael Mueller
2015-02-17 14:24 ` [Qemu-devel] [RFC PATCH v2 09/15] cpu-model/s390: Add KVM VM attribute interface routines Michael Mueller
2015-02-20 13:59   ` Alexander Graf
2015-02-20 15:18     ` Michael Mueller
2015-02-20 16:59       ` Alexander Graf
2015-02-20 18:42         ` Michael Mueller
2015-02-17 14:24 ` [Qemu-devel] [RFC PATCH v2 10/15] cpu-model/s390: Add cpu class initialization routines Michael Mueller
2015-02-20 16:02   ` Richard Henderson
2015-02-20 16:12     ` Michael Mueller
2015-02-20 16:27       ` Michael Mueller
2015-02-20 16:34       ` Andreas Färber
2015-02-20 16:55         ` Michael Mueller
2015-02-20 18:11   ` Richard Henderson
2015-02-20 18:59     ` Michael Mueller
2015-02-20 19:21       ` Alexander Graf
2015-02-20 19:35         ` Michael Mueller
2015-02-17 14:24 ` [Qemu-devel] [RFC PATCH v2 11/15] cpu-model/s390: Add QMP command query-cpu-model Michael Mueller
2015-02-17 18:03   ` Eric Blake
2015-02-18  8:39     ` Michael Mueller
2015-02-17 14:24 ` [Qemu-devel] [RFC PATCH v2 12/15] cpu-model/s390: Extend QMP command query-cpu-definitions Michael Mueller
2015-02-17 18:09   ` Eric Blake [this message]
2015-02-18  9:29     ` Michael Mueller
2015-02-17 14:24 ` [Qemu-devel] [RFC PATCH v2 13/15] cpu-model/s390: Add processor property routines Michael Mueller
2015-02-20 14:03   ` Alexander Graf
2015-02-20 15:32     ` Michael Mueller
2015-02-20 15:41       ` Andreas Färber
2015-02-20 16:04         ` Michael Mueller
2015-02-20 16:28           ` Andreas Färber
2015-02-20 16:53             ` Michael Mueller
2015-02-20 16:05         ` Michael Mueller
2015-02-20 17:00       ` Alexander Graf
2015-02-20 19:29         ` Michael Mueller
2015-02-17 14:24 ` [Qemu-devel] [RFC PATCH v2 14/15] cpu-model/s390: Add cpu model selection routine Michael Mueller
2015-02-17 14:24 ` [Qemu-devel] [RFC PATCH v2 15/15] cpu-model/s390: Enable S390 cpu model Michael Mueller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=54E383DE.5060902@redhat.com \
    --to=eblake@redhat.com \
    --cc=afaerber@suse.de \
    --cc=agraf@suse.de \
    --cc=borntraeger@de.ibm.com \
    --cc=cornelia.huck@de.ibm.com \
    --cc=gleb@kernel.org \
    --cc=jjherne@linux.vnet.ibm.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=mimu@linux.vnet.ibm.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=rth@twiddle.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).