On 02/02/2018 08:50 AM, Eduardo Habkost wrote:
(CCing qemu-devel)
On Fri, Feb 02, 2018 at 09:21:59AM -0500, Luiz Capitulino wrote:
> On Fri, 2 Feb 2018 14:19:38 +0000
> Daniel P. Berrangé <berrange(a)redhat.com> wrote:
>> On Fri, Feb 02, 2018 at 12:15:54PM -0200, Eduardo Habkost wrote:
[...]
>>> It would be also interesting to update QEMU QMP documentation to
>>> clarify the arch-specific semantics of "halted".
>>
>> Any also especially clarify the awful performance implications of running
>> this particular query command. In general I would not expect query-xxx
>> monitor commands to interrupt all vcpus, so we should clearly warn about
>> this !
>
> Or deprecate it...
We could deprecate the expensive fields on query-cpus, and move
them to a more expensive query-cpu-state command. I believe most
users of query-cpus are only interested in qom_path, thread_id,
and topology info.
Markus, Eric: from the QAPI point of view, is it OK to remove
fields between QEMU versions, as long as we follow our
deprecation policy?
Removing an output field outright may break a client that depended on
the field; so a deprecation period is definitely required there. But it
is okay, documentation-wise, to state that a field is output always as 0
for back-compatibility reasons and that modern clients should ignore it
(which would then let old clients still parse the field, but no longer
see a non-zero value), whether or not we also pursue the deprecation
course and eventually remove the field after more releases.
See CpuInfo::current, for an example.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization:
qemu.org |
libvirt.org