All of lore.kernel.org
 help / color / mirror / Atom feed
From: Markus Armbruster <armbru@redhat.com>
To: Laszlo Ersek <lersek@redhat.com>
Cc: Eric Blake <eblake@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Peter Crosthwaite <crosthwaite.peter@gmail.com>,
	qemu-devel@nongnu.org, Richard Henderson <rth@twiddle.net>
Subject: Re: [Qemu-devel] [PATCH 6/6] qapi: discriminate CpuInfo[Fast] on SysEmuTarget, not CpuInfoArch
Date: Fri, 27 Apr 2018 08:53:51 +0200	[thread overview]
Message-ID: <87bme5uolc.fsf@dusky.pond.sub.org> (raw)
In-Reply-To: <f0c9c7ca-3dcf-4f74-9812-5dea5b6376cd@redhat.com> (Laszlo Ersek's message of "Thu, 26 Apr 2018 18:30:19 +0200")

Laszlo Ersek <lersek@redhat.com> writes:

> On 04/26/18 17:51, Markus Armbruster wrote:
>> Eric Blake <eblake@redhat.com> writes:
>> 
>>> On 04/26/2018 09:34 AM, Markus Armbruster wrote:
>>>>>
>>>>> Acerbic discovery of the day: @CpuInfoArch has "x86", while configure
>>>>> produces:
>>>>>
>>>>>   TARGET_NAME  TARGET_BASE_ARCH
>>>>>          i386              i386
>>>>>        x86_64              i386
>>>>>
>>>>> Note how "i386" does not match "x86".
>>>>
>>>> Review fail.
>>>>
>>>> Just three weeks ago, we could still have fixed query-cpus-fast...
>>>
>>> Actually, I think we still can.  We already documented in the 2.12
>>> release notes that the "arch" field of query-cpus-fast is known to be
>>> broken for all but "s390x" (which is really the only arch field that
>>> MUST be correct, as that is the only time we send additional
>>> information).  And introspection can easily see both the enum contents
>>> (if we add something) as well as any other additions to the
>>> query-cpus-fast output union (although that is less likely), to use
>>> those as a witness for whether qemu is new enough to have fixed the
>>> bogus "arch" values.  I'd argue that if we change things right now, with
>>> intent to include the change in 2.12.1, before people start relying on
>>> the bogus "arch" of 2.12, then we should feel free to make
>>> query-cpus-fast output whatever we want for all architectures other than
>>> "s390x", even if it changes the current output of "x86".
>> 
>> In other words, we managed to screw up query-cpus-fast sufficiently to
>> let us fix it even now.  Cool, let's do it!
>> 
>
> Let me clarify a little.
>
> The @CpuInfoArch enum has the following constants now:
>
> ['x86', 'sparc', 'ppc', 'mips', 'tricore', 's390', 'riscv', 'other' ]
>
> This enum was originally introduced in 2.6 (according to the
> documentation), and only the @s390 and @riscv constants were added in 2.12.
>
> The enum constants show up in the following two places, *on the wire*:
>
> - in @CpuInfo.@arch, only produced by @query-cpus,
> - in @CpuInfoFast.@arch, only produced by @query-cpus-fast.
>
> The plan would be to rewrite *all* those enum constants of @CpuInfoArch
> to which the respective TARGET_BASE_ARCH values (from "configure") do
> not map *identically*. Here's the mapping:
>
>   TARGET_BASE_ARCH  CpuInfoArch  CpuInfoArch needs change
>   ----------------  -----------  ------------------------
>   i386              x86          YES
>   sparc             sparc        no
>   ppc               ppc          no
>   mips              mips         no
>   tricore           tricore      no
>   s390x             s390         YES
>   riscv             riscv        no
>
> In other words, @CpuInfoArch would have to be changed to the following:
>
> ['i386', 'sparc', 'ppc', 'mips', 'tricore', 's390x', 'riscv', 'other' ]
>  ^^^^^^                                     ^^^^^^^
>
> This means that the @arch field, returned by @query-cpus and
> @query-cpus-fast, would change incompatibly for those QAPI clients that
> look specifically for "x86" or "s390".
>
> Is this a safe change?
>
> I would say, because of the 's390' -> 's390x' change, that it isn't.
>
> (Also, to confirm, the wiki section at
> <https://wiki.qemu.org/Planning/2.12#Issues_that_will_not_be_fixed> states,
>
>   * the query-cpus-fast QMP command reports bogus arch data for all
>     architectures except x86 and s390; applications should be careful to
>     not rely on the bogus information
>
> It (correctly) refers to "s390". That value would change.)

You're right, that's a compatibility break.

We could perhaps still declare *all* @arch values useless in v2.12.0,
then fix them in v2.12.1.

Or we deprecate @arch right when we introduce @target, and drop it later
in accordance with our deprecation policy (qemu-doc.texi @appendix
Deprecated features).  That way, the rather ridiculous code to compute
it will be temporary.  I think that's cleaner.

   @arch in     query-cpus      query-cpus-fast
   before 2.6   nonexistent
   2.6 - 2.11   CpuInfoArch
   2.12         cmd deprecated  CpuInfoArch
   2.13         cmd deprecated  memb deprecated
   2.14         cmd gone        memb deprecated
   2.15         cmd gone        memb gone

Opinions?

  reply	other threads:[~2018-04-27  6:54 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-24 21:45 [Qemu-devel] [PATCH 0/6] qapi: introduce the SysEmuTarget enumeration Laszlo Ersek
2018-04-24 21:45 ` [Qemu-devel] [PATCH 1/6] qapi: fill in CpuInfoFast.arch in query-cpus-fast Laszlo Ersek
2018-04-24 22:30   ` Eric Blake
2018-04-25 12:30     ` Laszlo Ersek
2018-04-25  6:39   ` Markus Armbruster
2018-04-25 12:30     ` Laszlo Ersek
2018-04-25  7:28   ` Cornelia Huck
2018-04-24 21:45 ` [Qemu-devel] [PATCH 2/6] qapi: handle the riscv CpuInfoArch " Laszlo Ersek
2018-04-24 22:32   ` Eric Blake
2018-04-25 12:32     ` Laszlo Ersek
2018-04-25  6:44   ` Markus Armbruster
2018-04-25  7:48     ` Cornelia Huck
2018-04-25 12:38       ` Viktor VM Mihajlovski
2018-04-25 12:43       ` Laszlo Ersek
2018-04-24 21:45 ` [Qemu-devel] [PATCH 3/6] qapi: add SysEmuTarget to "common.json" Laszlo Ersek
2018-04-24 23:11   ` Eric Blake
2018-04-25 12:54     ` Daniel P. Berrangé
2018-04-25 19:05       ` Laszlo Ersek
2018-04-25 19:08         ` Eric Blake
2018-04-25 22:57           ` Laszlo Ersek
2018-04-24 21:45 ` [Qemu-devel] [PATCH 4/6] qapi: change the type of TargetInfo.arch from string to enum SysEmuTarget Laszlo Ersek
2018-04-25  6:48   ` Markus Armbruster
2018-04-25 12:58     ` Laszlo Ersek
2018-04-24 21:45 ` [Qemu-devel] [PATCH 5/6] qapi: extract CpuInfoCommon to mitigate schema duplication Laszlo Ersek
2018-04-25  7:06   ` Markus Armbruster
2018-04-25 13:20     ` Laszlo Ersek
2018-04-25 17:12       ` Markus Armbruster
2018-04-25 19:12       ` Eric Blake
2018-04-25 22:56         ` Laszlo Ersek
2018-04-26  6:19           ` Markus Armbruster
2018-04-24 21:45 ` [Qemu-devel] [PATCH 6/6] qapi: discriminate CpuInfo[Fast] on SysEmuTarget, not CpuInfoArch Laszlo Ersek
2018-04-25  7:33   ` Markus Armbruster
2018-04-25 13:47     ` Laszlo Ersek
2018-04-26  6:26       ` Markus Armbruster
2018-04-26  9:18         ` Laszlo Ersek
2018-04-26 11:57           ` Markus Armbruster
2018-04-26 13:33           ` Laszlo Ersek
2018-04-26 14:34             ` Markus Armbruster
2018-04-26 14:48               ` Eric Blake
2018-04-26 15:51                 ` Markus Armbruster
2018-04-26 16:30                   ` Laszlo Ersek
2018-04-27  6:53                     ` Markus Armbruster [this message]
2018-04-27 13:46                       ` Eric Blake
2018-04-24 22:03 ` [Qemu-devel] [PATCH 0/6] qapi: introduce the SysEmuTarget enumeration no-reply
2018-04-25 12:26   ` Laszlo Ersek
2018-04-25 14:37     ` Eric Blake

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=87bme5uolc.fsf@dusky.pond.sub.org \
    --to=armbru@redhat.com \
    --cc=crosthwaite.peter@gmail.com \
    --cc=eblake@redhat.com \
    --cc=lersek@redhat.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 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.