qemu-stable
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-stable] [Qemu-devel] [PATCH 1/6] qapi: fill in CpuInfoFast.arc


From: Markus Armbruster
Subject: Re: [Qemu-stable] [Qemu-devel] [PATCH 1/6] qapi: fill in CpuInfoFast.arch in query-cpus-fast
Date: Wed, 25 Apr 2018 08:39:38 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux)

Laszlo Ersek <address@hidden> writes:

> Commit ca230ff33f89 added 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().

Now I'm confused.

In the schema, @arch "riscv" implies CpuInfoRISCV:

    { 'union': 'CpuInfoFast',
      'base': {'cpu-index': 'int', 'qom-path': 'str',
               'thread-id': 'int', '*props': 'CpuInstanceProperties',
               'arch': 'CpuInfoArch' },
      'discriminator': 'arch',
      'data': { 'x86': 'CpuInfoOther',
                'sparc': 'CpuInfoOther',
                'ppc': 'CpuInfoOther',
                'mips': 'CpuInfoOther',
                'tricore': 'CpuInfoOther',
                's390': 'CpuInfoS390',
                'riscv': 'CpuInfoRISCV',
                'other': 'CpuInfoOther' } }

In qmp_query_cpus_fast(), it can't imply anything, because can't occur.
That's a bug, and this patch fixes it.  Except it sets @arch to "other"
instead of "riscv" when defined(TARGET_RISCV).  Why?  Oh, I see, that
gets fixed in the next patch.  Please explain that in your commit
message, or squash the two patches.  The latter feels simpler, so that's
what I'd do.

>
> Cc: Eric Blake <address@hidden>
> Cc: Markus Armbruster <address@hidden>
> Cc: Paolo Bonzini <address@hidden>
> Cc: Peter Crosthwaite <address@hidden>
> Cc: Richard Henderson <address@hidden>
> Cc: address@hidden
> Fixes: ca230ff33f89bf7102cbfbc2328716da6750aaed
> Signed-off-by: Laszlo Ersek <address@hidden>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]