Skip to content
  • Laszlo Ersek's avatar
    96054f56
    qapi: fill in CpuInfoFast.arch in query-cpus-fast · 96054f56
    Laszlo Ersek authored
    * Commit ca230ff3 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 25fa194b 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: ca230ff3
    Fixes: 25fa194b
    Signed-off-by: default avatarLaszlo Ersek <lersek@redhat.com>
    Reviewed-by: default avatarEric Blake <eblake@redhat.com>
    Reviewed-by: default avatarCornelia Huck <cohuck@redhat.com>
    Reviewed-by: default avatarMarkus Armbruster <armbru@redhat.com>
    Message-Id: <20180427192852.15013-2-lersek@redhat.com>
    Signed-off-by: default avatarMarkus Armbruster <armbru@redhat.com>
    96054f56
    qapi: fill in CpuInfoFast.arch in query-cpus-fast
    Laszlo Ersek authored
    * Commit ca230ff3 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 25fa194b 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: ca230ff3
    Fixes: 25fa194b
    Signed-off-by: default avatarLaszlo Ersek <lersek@redhat.com>
    Reviewed-by: default avatarEric Blake <eblake@redhat.com>
    Reviewed-by: default avatarCornelia Huck <cohuck@redhat.com>
    Reviewed-by: default avatarMarkus Armbruster <armbru@redhat.com>
    Message-Id: <20180427192852.15013-2-lersek@redhat.com>
    Signed-off-by: default avatarMarkus Armbruster <armbru@redhat.com>
Loading