All of lore.kernel.org
 help / color / mirror / Atom feed
From: Markus Armbruster <armbru@redhat.com>
To: Laszlo Ersek <lersek@redhat.com>
Cc: qemu devel list <qemu-devel@nongnu.org>,
	qemu-stable@nongnu.org, Cornelia Huck <cohuck@redhat.com>,
	Viktor VM Mihajlovski <mihajlov@linux.vnet.ibm.com>
Subject: Re: [Qemu-devel] [PATCH v2 1/4] qapi: fill in CpuInfoFast.arch in query-cpus-fast
Date: Fri, 27 Apr 2018 09:18:17 +0200	[thread overview]
Message-ID: <877eotungm.fsf@dusky.pond.sub.org> (raw)
In-Reply-To: <20180426183404.3756-2-lersek@redhat.com> (Laszlo Ersek's message of "Thu, 26 Apr 2018 20:34:01 +0200")

Laszlo Ersek <lersek@redhat.com> writes:

> * Commit ca230ff33f89 added the @arch field to @CpuInfoFast, but it failed
>   to set the new field in qmp_query_cpus_fast(), when TARGET_S390X was not
>   defined. The updated @query-cpus-fast example in "qapi-schema.json"
>   showed "arch":"x86" only because qmp_query_cpus_fast() calls g_malloc0()
>   to allocate @CpuInfoFast, and the CPU_INFO_ARCH_X86 enum constant is
>   generated with value 0.
>
>   All @arch values other than @s390 implied the @CpuInfoOther sub-struct
>   for @CpuInfoFast -- at the time of writing the patch --, thus no fields
>   other than @arch needed to be set when TARGET_S390X was not defined. Set
>   @arch now, by copying the corresponding assignments from
>   qmp_query_cpus().
>
> * Commit 25fa194b7b11 added the @riscv enum constant to @CpuInfoArch (used
>   in both @CpuInfo and @CpuInfoFast -- the return types of the @query-cpus
>   and @query-cpus-fast commands, respectively), and assigned, in both
>   return structures, the @CpuInfoRISCV sub-structure to the new enum
>   value.
>
>   However, qmp_query_cpus_fast() would not populate either the @arch field
>   or the @CpuInfoRISCV sub-structure, when TARGET_RISCV was defined; only
>   qmp_query_cpus() would.
>
>   Assign @CpuInfoOther to the @riscv enum constant in @CpuInfoFast, and
>   populate only the @arch field in qmp_query_cpus_fast(). Getting CPU
>   state without interrupting KVM is an exceptional thing that only S390X
>   does currently. Quoting Cornelia Huck <cohuck@redhat.com>, "s390x is
>   exceptional in that it has state in QEMU that is actually interesting
>   for upper layers and can be retrieved without performance penalty". See
>   also
>   <https://www.redhat.com/archives/libvir-list/2018-February/msg00121.html>.
>
> Cc: Cornelia Huck <cohuck@redhat.com>
> Cc: Eric Blake <eblake@redhat.com>
> Cc: Markus Armbruster <armbru@redhat.com>
> Cc: Viktor VM Mihajlovski <mihajlov@linux.vnet.ibm.com>
> Cc: qemu-stable@nongnu.org
> Fixes: ca230ff33f89bf7102cbfbc2328716da6750aaed
> Fixes: 25fa194b7b11901561532e435beb83d046899f7a
> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
> Reviewed-by: Eric Blake <eblake@redhat.com>

Reviewed-by: Markus Armbruster <armbru@redhat.com>

  parent reply	other threads:[~2018-04-27  7:18 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-26 18:34 [Qemu-devel] [PATCH v2 0/4] qapi: introduce the SysEmuTarget enumeration Laszlo Ersek
2018-04-26 18:34 ` [Qemu-devel] [PATCH v2 1/4] qapi: fill in CpuInfoFast.arch in query-cpus-fast Laszlo Ersek
2018-04-27  7:05   ` Cornelia Huck
2018-04-27  7:18   ` Markus Armbruster [this message]
2018-04-26 18:34 ` [Qemu-devel] [PATCH v2 2/4] qapi: add SysEmuTarget to "common.json" Laszlo Ersek
2018-04-26 19:27   ` Eric Blake
2018-04-27  7:18   ` Markus Armbruster
2018-04-26 18:34 ` [Qemu-devel] [PATCH v2 3/4] qapi: change the type of TargetInfo.arch from string to enum SysEmuTarget Laszlo Ersek
2018-04-26 19:31   ` Eric Blake
2018-04-26 18:34 ` [Qemu-devel] [PATCH v2 4/4] qapi: discriminate CpuInfoFast on SysEmuTarget, not CpuInfoArch Laszlo Ersek
2018-04-26 19:41   ` Eric Blake
2018-04-26 19:45     ` Eric Blake
2018-04-27  7:29   ` Markus Armbruster

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=877eotungm.fsf@dusky.pond.sub.org \
    --to=armbru@redhat.com \
    --cc=cohuck@redhat.com \
    --cc=lersek@redhat.com \
    --cc=mihajlov@linux.vnet.ibm.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-stable@nongnu.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.