On Tue, 13 Feb 2018 18:18:48 +0100
Viktor Mihajlovski <mihaj...@linux.vnet.ibm.com> wrote:
> The s390 CPU state can be retrieved without interrupting the
> VM execution. Extendend the CpuInfoFast union with architecture
> specific data and an implementation for s390.
>
> Return data looks like this:
> [
> {"thread-id":64301,"props":{"core-id":0},
> "arch":"s390","cpu-state":"operating",
> "qom-path":"/machine/unattached/device[0]","cpu-index":0},
> {"thread-id":64302,"props":{"core-id":1},
> "arch":"s390","cpu-state":"operating",
> "qom-path":"/machine/unattached/device[1]","cpu-index":1}
> ]
>
> Currently there's a certain amount of duplication between
> the definitions of CpuInfo and CpuInfoFast, both in the
> base and variable areas, since there are data fields common
> to the slow and fast variants.
>
> A suggestion was made on the mailing list to enhance the QAPI
> code generation to support two layers of unions. This would
> allow to specify the common fields once and avoid the duplication
> in the leaf unions.
>
> On the other hand, the slow query-cpus should be deprecated
> along with the slow CpuInfo type and eventually be removed.
> Assuming that new architectures will not be added at high
> rates, we could live with the duplication for the time being.
What would be a realistic timeframe for deprecation/removal of
query-cpus, considering the libvirt usage? Are we aware of other users?
>
> Signed-off-by: Viktor Mihajlovski <mihaj...@linux.vnet.ibm.com>
> ---
> cpus.c | 10 ++++++++++
> hmp.c | 10 ++++++++++
> qapi-schema.json | 35 +++++++++++++++++++++++++++++------
> 3 files changed, 49 insertions(+), 6 deletions(-)
Patch looks good to me.
Reviewed-by: Cornelia Huck <coh...@redhat.com>
