Laszlo Ersek <ler...@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 <coh...@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 <coh...@redhat.com> > Cc: Eric Blake <ebl...@redhat.com> > Cc: Markus Armbruster <arm...@redhat.com> > Cc: Viktor VM Mihajlovski <mihaj...@linux.vnet.ibm.com> > Cc: qemu-sta...@nongnu.org > Fixes: ca230ff33f89bf7102cbfbc2328716da6750aaed > Fixes: 25fa194b7b11901561532e435beb83d046899f7a > Signed-off-by: Laszlo Ersek <ler...@redhat.com> > Reviewed-by: Eric Blake <ebl...@redhat.com>
Reviewed-by: Markus Armbruster <arm...@redhat.com>