On 12.02.2018 19:03, Luiz Capitulino wrote: > On Mon, 12 Feb 2018 13:14:30 +0100 > Viktor Mihajlovski <mihaj...@linux.vnet.ibm.com> wrote: > >> Presently s390x is the only architecture not exposing specific >> CPU information via QMP query-cpus. Upstream discussion has shown >> that it could make sense to report the architecture specific CPU >> state, e.g. to detect that a CPU has been stopped. >> >> With this change the output of query-cpus will look like this on >> s390: >> >> [ >> {"arch": "s390", "current": true, >> "props": {"core-id": 0}, "cpu-state": "operating", "CPU": 0, >> "qom_path": "/machine/unattached/device[0]", >> "halted": false, "thread_id": 63115}, >> {"arch": "s390", "current": false, >> "props": {"core-id": 1}, "cpu-state": "stopped", "CPU": 1, >> "qom_path": "/machine/unattached/device[1]", >> "halted": true, "thread_id": 63116} >> ] > > We're adding the same information to query-cpus-fast. Why do we > need to duplicate this into query-cpus? Do you plan to keep using > query-cpus? If yes, why?
Wonder if we could simply pass a flag to query-cpus "fast=true", that makes it behave differently. (either not indicate the critical values or simply provide dummy values - e.g. simply halted=false) > > Libvirt for one, should move away from it. We don't want to run > into the risk of having the same issue we had with x86 in other > archs. > >> -- Thanks, David / dhildenb