On 04/24/2018 07:46 AM, Laszlo Ersek wrote: > I just noticed two QAPI bugs introduced in 2.12, in the following two > commits: > > (1) ca230ff33f89 ("qmp: add architecture specific cpu data for > query-cpus-fast", 2018-02-26) > > This commit added @arch to @CpuInfoFast, but it failed to set the new > field to CPU_INFO_ARCH_OTHER in qmp_query_cpus_fast(), when TARGET_S390X > is not defined.
We zero-initialize info->value, and info->value->arch == 0 happens to be CPU_INFO_ARCH_X86 which is associated with the empty type CpuInfoOther, which is no different than what we would have had with CPU_INFO_ARCH_OTHER. So the drawback is that on x86 architectures, things look correct; while on sparc, ppc, mips, and tricore (which have a specific type) and on all other platforms (which should use "other"), the output wrongly reports "arch":"x86" but does not crash. > > (2) 25fa194b7b11 ("RISC-V Build Infrastructure", 2018-03-07) > > This commit 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. Ouch - we SHOULD have used 'CpuInfoOther' rather than 'CpuInfoRISCV' for @CpuInfoFast. We do NOT want to report the 'pc' field in the fast query. > > However, qmp_query_cpus_fast() does not populate the sub-structure, when > TARGET_RISCV is defined; only qmp_query_cpus() does. Indeed, the output wrongly reports "arch":"x86" instead of "arch":"riscv" - but at least things do not crash. > > The fixes don't look complicated. Do you want to hold the release while > I post the fixes? > > I don't think these bugs are "show stoppers". On the other hand, QAPI is > an external interface. It's too late for the 2.12 release. We'll definitely fix things in 2.12.1 (so cc the patches to qemu-stable), and should document in the release notes that query-cpus-fast is known to report bogus "arch" data for all architectures except x86 and s390, so applications should be careful to not rely on the bogus information. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature