* [Qemu-devel] [PATCH v1 0/2] QMP: implementing qmp_cpu @ 2017-12-13 18:15 Daniel Henrique Barboza 2017-12-13 18:15 ` [Qemu-devel] [PATCH v1 1/2] qmp.c: (re)implement qmp_cpu Daniel Henrique Barboza 2017-12-13 18:15 ` [Qemu-devel] [PATCH v1 2/2] cpus.c: change qmp_query_cpus 'value->current' logic Daniel Henrique Barboza 0 siblings, 2 replies; 12+ messages in thread From: Daniel Henrique Barboza @ 2017-12-13 18:15 UTC (permalink / raw) To: qemu-devel; +Cc: dgilbert, armbru, Daniel Henrique Barboza This small series (re)implements qmp_cpu inside qmp.c, adapting docs and hmp code accordingly. A fix was also made in qmp_query_cpus in resulting of the qmp_cpu usage. The first and unique qmp_cpu implementation so far was made in commit 755f196898, ("qapi: Convert the cpu command"). This is a 6 year old commit that was part of the following series: https://lists.gnu.org/archive/html/qemu-devel/2011-10/msg02767.html I don't understand in the original context why the qmp_cpu function was left blank while implementing hmp_cpu, but today I believe we can have both qmp_cpu and hmp_cpu co-existing. Daniel Henrique Barboza (2): qmp.c: (re)implement qmp_cpu cpus.c: change qmp_query_cpus 'value->current' logic cpus.c | 2 +- hmp.c | 14 ++++---------- qapi-schema.json | 14 +++++++++++--- qmp.c | 4 +++- 4 files changed, 19 insertions(+), 15 deletions(-) -- 2.13.6 ^ permalink raw reply [flat|nested] 12+ messages in thread
* [Qemu-devel] [PATCH v1 1/2] qmp.c: (re)implement qmp_cpu 2017-12-13 18:15 [Qemu-devel] [PATCH v1 0/2] QMP: implementing qmp_cpu Daniel Henrique Barboza @ 2017-12-13 18:15 ` Daniel Henrique Barboza 2017-12-14 2:18 ` Eric Blake 2017-12-13 18:15 ` [Qemu-devel] [PATCH v1 2/2] cpus.c: change qmp_query_cpus 'value->current' logic Daniel Henrique Barboza 1 sibling, 1 reply; 12+ messages in thread From: Daniel Henrique Barboza @ 2017-12-13 18:15 UTC (permalink / raw) To: qemu-devel; +Cc: dgilbert, armbru, Daniel Henrique Barboza Commit 755f196898 ("qapi: Convert the cpu command") added the qmp_cpu function in qmp.c, leaving it blank. It the same commit, a working hmp_cpu was implemented. Since then, no further changes were made in qmp_cpu, resulting now in a working 'cpu' command that works in HMP and a 'cpu' command in QMP that does nothing. Regardless of what constraints were involved that time in not implemeting qmp_cpu, at this moment it is possible to have both. This patch brings the logic of hmp_cpu to qmp_cpu and converts the HMP function to use its QMP counterpart. Signed-off-by: Daniel Henrique Barboza <danielhb@linux.vnet.ibm.com> --- hmp.c | 8 +++----- qapi-schema.json | 14 +++++++++++--- qmp.c | 4 +++- 3 files changed, 17 insertions(+), 9 deletions(-) diff --git a/hmp.c b/hmp.c index 35a7041824..7506f105a0 100644 --- a/hmp.c +++ b/hmp.c @@ -1070,13 +1070,11 @@ void hmp_system_powerdown(Monitor *mon, const QDict *qdict) void hmp_cpu(Monitor *mon, const QDict *qdict) { int64_t cpu_index; + Error *err = NULL; - /* XXX: drop the monitor_set_cpu() usage when all HMP commands that - use it are converted to the QAPI */ cpu_index = qdict_get_int(qdict, "index"); - if (monitor_set_cpu(cpu_index) < 0) { - monitor_printf(mon, "invalid CPU index\n"); - } + qmp_cpu(cpu_index, &err); + hmp_handle_error(mon, &err); } void hmp_memsave(Monitor *mon, const QDict *qdict) diff --git a/qapi-schema.json b/qapi-schema.json index 18457954a8..4c8f2d405e 100644 --- a/qapi-schema.json +++ b/qapi-schema.json @@ -1048,11 +1048,19 @@ ## # @cpu: # -# This command is a nop that is only provided for the purposes of compatibility. +# Set the default CPU. # -# Since: 0.14.0 +# @index: The index of the virtual CPU to be set as default +# +# Returns: Nothing on success +# +# Since: 2.12.0 +# +# Example: +# +# -> { "execute": "cpu", "arguments": { "index": 2 } } +# <- { "return": {} } # -# Notes: Do not use this command. ## { 'command': 'cpu', 'data': {'index': 'int'} } diff --git a/qmp.c b/qmp.c index e8c303116a..c482225d5c 100644 --- a/qmp.c +++ b/qmp.c @@ -115,7 +115,9 @@ void qmp_system_powerdown(Error **erp) void qmp_cpu(int64_t index, Error **errp) { - /* Just do nothing */ + if (monitor_set_cpu(index) < 0) { + error_setg(errp, "Invalid CPU index"); + } } void qmp_cpu_add(int64_t id, Error **errp) -- 2.13.6 ^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: [Qemu-devel] [PATCH v1 1/2] qmp.c: (re)implement qmp_cpu 2017-12-13 18:15 ` [Qemu-devel] [PATCH v1 1/2] qmp.c: (re)implement qmp_cpu Daniel Henrique Barboza @ 2017-12-14 2:18 ` Eric Blake 2017-12-14 15:21 ` Markus Armbruster 0 siblings, 1 reply; 12+ messages in thread From: Eric Blake @ 2017-12-14 2:18 UTC (permalink / raw) To: Daniel Henrique Barboza, qemu-devel; +Cc: dgilbert, armbru [-- Attachment #1: Type: text/plain, Size: 2478 bytes --] On 12/13/2017 12:15 PM, Daniel Henrique Barboza wrote: > Commit 755f196898 ("qapi: Convert the cpu command") added the qmp_cpu > function in qmp.c, leaving it blank. It the same commit, a working > hmp_cpu was implemented. Since then, no further changes were made in > qmp_cpu, resulting now in a working 'cpu' command that works in HMP > and a 'cpu' command in QMP that does nothing. > > Regardless of what constraints were involved that time in not implemeting > qmp_cpu, at this moment it is possible to have both. This patch brings > the logic of hmp_cpu to qmp_cpu and converts the HMP function to use its > QMP counterpart. I'm not sure I like this. HMP is stateful (you have to remember what previous 'cpu' commands have been run to tell what the current command will do). That may be convenient (if not confusing) to humans, but is lousy for machine interfaces. QMP should be stateless as much as possible - for any command that would behave differently according to what CPU is selected, THAT command (and not a different 'cpu' command executed previously) should have a cpu argument alongside all its other parameters. So unless you have a really strong use case for this, I don't think we want it. > +++ b/qapi-schema.json > @@ -1048,11 +1048,19 @@ > ## > # @cpu: > # > -# This command is a nop that is only provided for the purposes of compatibility. > +# Set the default CPU. > # > -# Since: 0.14.0 > +# @index: The index of the virtual CPU to be set as default > +# > +# Returns: Nothing on success > +# > +# Since: 2.12.0 > +# > +# Example: > +# > +# -> { "execute": "cpu", "arguments": { "index": 2 } } > +# <- { "return": {} } > # > -# Notes: Do not use this command. > ## > { 'command': 'cpu', 'data': {'index': 'int'} } > > diff --git a/qmp.c b/qmp.c > index e8c303116a..c482225d5c 100644 > --- a/qmp.c > +++ b/qmp.c > @@ -115,7 +115,9 @@ void qmp_system_powerdown(Error **erp) > > void qmp_cpu(int64_t index, Error **errp) > { > - /* Just do nothing */ > + if (monitor_set_cpu(index) < 0) { > + error_setg(errp, "Invalid CPU index"); > + } > } > > void qmp_cpu_add(int64_t id, Error **errp) > Better yet, let's document that 'cpu' is deprecated, so that we can remove it from QMP altogether in a couple of releases. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 619 bytes --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Qemu-devel] [PATCH v1 1/2] qmp.c: (re)implement qmp_cpu 2017-12-14 2:18 ` Eric Blake @ 2017-12-14 15:21 ` Markus Armbruster 2017-12-14 19:46 ` Daniel Henrique Barboza 0 siblings, 1 reply; 12+ messages in thread From: Markus Armbruster @ 2017-12-14 15:21 UTC (permalink / raw) To: Eric Blake; +Cc: Daniel Henrique Barboza, qemu-devel, dgilbert Eric Blake <eblake@redhat.com> writes: > On 12/13/2017 12:15 PM, Daniel Henrique Barboza wrote: >> Commit 755f196898 ("qapi: Convert the cpu command") added the qmp_cpu >> function in qmp.c, leaving it blank. It the same commit, a working >> hmp_cpu was implemented. Since then, no further changes were made in >> qmp_cpu, resulting now in a working 'cpu' command that works in HMP >> and a 'cpu' command in QMP that does nothing. >> >> Regardless of what constraints were involved that time in not implemeting >> qmp_cpu, at this moment it is possible to have both. If I remember that part of history correctly, implementing the command in QMP was just as possible back then, but deemed a Bad Idea for the reason Eric explains below. What I don't quite remember is why we had to implement it in QMP as a no-op. Might have been due to the way QMP and HMP were entangled back then. >> This patch brings >> the logic of hmp_cpu to qmp_cpu and converts the HMP function to use its >> QMP counterpart. > > I'm not sure I like this. HMP is stateful (you have to remember what > previous 'cpu' commands have been run to tell what the current command > will do). That may be convenient (if not confusing) to humans, but is > lousy for machine interfaces. QMP should be stateless as much as > possible - for any command that would behave differently according to > what CPU is selected, THAT command (and not a different 'cpu' command > executed previously) should have a cpu argument alongside all its other > parameters. > > So unless you have a really strong use case for this, I don't think we > want it. > > >> +++ b/qapi-schema.json >> @@ -1048,11 +1048,19 @@ >> ## >> # @cpu: >> # >> -# This command is a nop that is only provided for the purposes of compatibility. >> +# Set the default CPU. >> # >> -# Since: 0.14.0 >> +# @index: The index of the virtual CPU to be set as default >> +# >> +# Returns: Nothing on success >> +# >> +# Since: 2.12.0 >> +# >> +# Example: >> +# >> +# -> { "execute": "cpu", "arguments": { "index": 2 } } >> +# <- { "return": {} } >> # >> -# Notes: Do not use this command. >> ## >> { 'command': 'cpu', 'data': {'index': 'int'} } >> >> diff --git a/qmp.c b/qmp.c >> index e8c303116a..c482225d5c 100644 >> --- a/qmp.c >> +++ b/qmp.c >> @@ -115,7 +115,9 @@ void qmp_system_powerdown(Error **erp) >> >> void qmp_cpu(int64_t index, Error **errp) >> { >> - /* Just do nothing */ >> + if (monitor_set_cpu(index) < 0) { >> + error_setg(errp, "Invalid CPU index"); >> + } >> } >> >> void qmp_cpu_add(int64_t id, Error **errp) >> > > Better yet, let's document that 'cpu' is deprecated, so that we can > remove it from QMP altogether in a couple of releases. Yes. The standard way to deprecate a feature is to add it to appendix "Deprecated features" in qemu-doc.texi, and make its use trigger suitable deprecation messages, pointing to a replacement if any. Unfortunately, we still lack means to signal "X is deprecated, use Y instead" to a QMP client. Not important in this case, because the command has never worked. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Qemu-devel] [PATCH v1 1/2] qmp.c: (re)implement qmp_cpu 2017-12-14 15:21 ` Markus Armbruster @ 2017-12-14 19:46 ` Daniel Henrique Barboza 2017-12-15 13:56 ` Markus Armbruster 2017-12-15 18:59 ` Dr. David Alan Gilbert 0 siblings, 2 replies; 12+ messages in thread From: Daniel Henrique Barboza @ 2017-12-14 19:46 UTC (permalink / raw) To: Markus Armbruster, Eric Blake; +Cc: qemu-devel, dgilbert On 12/14/2017 01:21 PM, Markus Armbruster wrote: > Eric Blake <eblake@redhat.com> writes: > >> On 12/13/2017 12:15 PM, Daniel Henrique Barboza wrote: >>> Commit 755f196898 ("qapi: Convert the cpu command") added the qmp_cpu >>> function in qmp.c, leaving it blank. It the same commit, a working >>> hmp_cpu was implemented. Since then, no further changes were made in >>> qmp_cpu, resulting now in a working 'cpu' command that works in HMP >>> and a 'cpu' command in QMP that does nothing. >>> >>> Regardless of what constraints were involved that time in not implemeting >>> qmp_cpu, at this moment it is possible to have both. > If I remember that part of history correctly, implementing the command > in QMP was just as possible back then, but deemed a Bad Idea for the > reason Eric explains below. > > What I don't quite remember is why we had to implement it in QMP as a > no-op. Might have been due to the way QMP and HMP were entangled back > then. Speaking of QMP and HMP 'entanglement', is the content of the wiki still valid? https://wiki.qemu.org/Features/QAPI And under "HMP Conversion" we have: "For HMP commands that don't have QMP equivalents today, new QMP functions will be added to support these commands." This in particular gave me the motivation to go ahead and implement qmp_cpu. But then again, the last entry on Status is "3/6/2011" so yeah, I should have asked here first whether the info from this wiki was relevant before sending the patch. >>> This patch brings >>> the logic of hmp_cpu to qmp_cpu and converts the HMP function to use its >>> QMP counterpart. >> I'm not sure I like this. HMP is stateful (you have to remember what >> previous 'cpu' commands have been run to tell what the current command >> will do). That may be convenient (if not confusing) to humans, but is >> lousy for machine interfaces. QMP should be stateless as much as >> possible - for any command that would behave differently according to >> what CPU is selected, THAT command (and not a different 'cpu' command >> executed previously) should have a cpu argument alongside all its other >> parameters. >> >> So unless you have a really strong use case for this, I don't think we >> want it. My case was simply "HMP has it, QMP doesn't". I wasn't aware that QMP must be as stateless as possible but HMP can retain state. Now, is there any command that actually is impacted or makes use of the current monitor CPU? I've searched a bit in qapi-schema.json and hmp-commands.hx and haven't found any (although this does not mean necessarily that no command is making use of it). Supposing that no command makes good use of it, perhaps it's a good exercise to evaluate if both qmp_cpu and hmp_cpu should be deprecated. >> >> >>> +++ b/qapi-schema.json >>> @@ -1048,11 +1048,19 @@ >>> ## >>> # @cpu: >>> # >>> -# This command is a nop that is only provided for the purposes of compatibility. >>> +# Set the default CPU. >>> # >>> -# Since: 0.14.0 >>> +# @index: The index of the virtual CPU to be set as default >>> +# >>> +# Returns: Nothing on success >>> +# >>> +# Since: 2.12.0 >>> +# >>> +# Example: >>> +# >>> +# -> { "execute": "cpu", "arguments": { "index": 2 } } >>> +# <- { "return": {} } >>> # >>> -# Notes: Do not use this command. >>> ## >>> { 'command': 'cpu', 'data': {'index': 'int'} } >>> >>> diff --git a/qmp.c b/qmp.c >>> index e8c303116a..c482225d5c 100644 >>> --- a/qmp.c >>> +++ b/qmp.c >>> @@ -115,7 +115,9 @@ void qmp_system_powerdown(Error **erp) >>> >>> void qmp_cpu(int64_t index, Error **errp) >>> { >>> - /* Just do nothing */ >>> + if (monitor_set_cpu(index) < 0) { >>> + error_setg(errp, "Invalid CPU index"); >>> + } >>> } >>> >>> void qmp_cpu_add(int64_t id, Error **errp) >>> >> Better yet, let's document that 'cpu' is deprecated, so that we can >> remove it from QMP altogether in a couple of releases. > Yes. > > The standard way to deprecate a feature is to add it to appendix > "Deprecated features" in qemu-doc.texi, and make its use trigger > suitable deprecation messages, pointing to a replacement if any. I'll give a try. Daniel > > Unfortunately, we still lack means to signal "X is deprecated, use Y > instead" to a QMP client. Not important in this case, because the > command has never worked. > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Qemu-devel] [PATCH v1 1/2] qmp.c: (re)implement qmp_cpu 2017-12-14 19:46 ` Daniel Henrique Barboza @ 2017-12-15 13:56 ` Markus Armbruster 2017-12-15 18:11 ` Paolo Bonzini 2017-12-15 18:59 ` Dr. David Alan Gilbert 1 sibling, 1 reply; 12+ messages in thread From: Markus Armbruster @ 2017-12-15 13:56 UTC (permalink / raw) To: Daniel Henrique Barboza; +Cc: Eric Blake, qemu-devel, dgilbert, Paolo Bonzini Daniel Henrique Barboza <danielhb@linux.vnet.ibm.com> writes: > On 12/14/2017 01:21 PM, Markus Armbruster wrote: >> Eric Blake <eblake@redhat.com> writes: >> >>> On 12/13/2017 12:15 PM, Daniel Henrique Barboza wrote: >>>> Commit 755f196898 ("qapi: Convert the cpu command") added the qmp_cpu >>>> function in qmp.c, leaving it blank. It the same commit, a working >>>> hmp_cpu was implemented. Since then, no further changes were made in >>>> qmp_cpu, resulting now in a working 'cpu' command that works in HMP >>>> and a 'cpu' command in QMP that does nothing. >>>> >>>> Regardless of what constraints were involved that time in not implemeting >>>> qmp_cpu, at this moment it is possible to have both. >> If I remember that part of history correctly, implementing the command >> in QMP was just as possible back then, but deemed a Bad Idea for the >> reason Eric explains below. >> >> What I don't quite remember is why we had to implement it in QMP as a >> no-op. Might have been due to the way QMP and HMP were entangled back >> then. > Speaking of QMP and HMP 'entanglement', is the content of the wiki > still valid? > > https://wiki.qemu.org/Features/QAPI Looks quite stale to me. I'm sorry this made you go down this rabbit hole. Paolo, we have numerous Features/ pages, and I suspect many of them are too outdated to serve any purpose but confusing readers. In theory, "somebody" could go through them to identify stale ones. In practice, "somebody" doesn't exist, I'm afraid. Should we summarily delete Features/ pages that haven't seen an update in say more than a year? Or at least mark them as obsolete somehow? > And under "HMP Conversion" we have: > > "For HMP commands that don't have QMP equivalents today, new QMP functions > will be added to support these commands." QMP need not provide the exact same commands. It must provide "equivalence". Selecting a CPU is an instructive example. HMP does it with state: each HMP monitor has a current CPU, controlled with HMP command cpu. HMP commands implicitly use their monitor's current CPU. In contrast, QMP eschews state, and makes the CPU explicit instead: you specify the it as an argument. > This in particular gave me the motivation to go ahead and implement qmp_cpu. > But then again, the last entry on Status is "3/6/2011" so yeah, I > should have > asked here first whether the info from this wiki was relevant before sending > the patch. Touching base with the maintainer(s) first generally doesn't hurt. [...] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Qemu-devel] [PATCH v1 1/2] qmp.c: (re)implement qmp_cpu 2017-12-15 13:56 ` Markus Armbruster @ 2017-12-15 18:11 ` Paolo Bonzini 2017-12-18 9:20 ` Markus Armbruster 0 siblings, 1 reply; 12+ messages in thread From: Paolo Bonzini @ 2017-12-15 18:11 UTC (permalink / raw) To: Markus Armbruster, Daniel Henrique Barboza; +Cc: qemu-devel, dgilbert On 15/12/2017 14:56, Markus Armbruster wrote: > > Paolo, we have numerous Features/ pages, and I suspect many of them are > too outdated to serve any purpose but confusing readers. In theory, > "somebody" could go through them to identify stale ones. In practice, > "somebody" doesn't exist, I'm afraid. Should we summarily delete > Features/ pages that haven't seen an update in say more than a year? Or > at least mark them as obsolete somehow? Plenty of them are marked as complete or obsolete: https://wiki.qemu.org/Category:Completed_feature_pages https://wiki.qemu.org/Category:Obsolete_feature_pages Last time I cleaned them up, I couldn't quite decide if some were completed or obsolete, and QAPI is one of them. Paolo ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Qemu-devel] [PATCH v1 1/2] qmp.c: (re)implement qmp_cpu 2017-12-15 18:11 ` Paolo Bonzini @ 2017-12-18 9:20 ` Markus Armbruster 0 siblings, 0 replies; 12+ messages in thread From: Markus Armbruster @ 2017-12-18 9:20 UTC (permalink / raw) To: Paolo Bonzini; +Cc: Daniel Henrique Barboza, qemu-devel, dgilbert Paolo Bonzini <pbonzini@redhat.com> writes: > On 15/12/2017 14:56, Markus Armbruster wrote: >> >> Paolo, we have numerous Features/ pages, and I suspect many of them are >> too outdated to serve any purpose but confusing readers. In theory, >> "somebody" could go through them to identify stale ones. In practice, >> "somebody" doesn't exist, I'm afraid. Should we summarily delete >> Features/ pages that haven't seen an update in say more than a year? Or >> at least mark them as obsolete somehow? > > Plenty of them are marked as complete or obsolete: > > https://wiki.qemu.org/Category:Completed_feature_pages > https://wiki.qemu.org/Category:Obsolete_feature_pages I see. > Last time I cleaned them up, I couldn't quite decide if some were > completed or obsolete, and QAPI is one of them. Probably because Features/QAPI is both: it was completed long ago, less a number of ideas described in this page. The page should be updated accordingly. I'll try to find time for it, but don't hold your breath. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Qemu-devel] [PATCH v1 1/2] qmp.c: (re)implement qmp_cpu 2017-12-14 19:46 ` Daniel Henrique Barboza 2017-12-15 13:56 ` Markus Armbruster @ 2017-12-15 18:59 ` Dr. David Alan Gilbert 2017-12-18 9:12 ` Markus Armbruster 1 sibling, 1 reply; 12+ messages in thread From: Dr. David Alan Gilbert @ 2017-12-15 18:59 UTC (permalink / raw) To: Daniel Henrique Barboza; +Cc: Markus Armbruster, Eric Blake, qemu-devel * Daniel Henrique Barboza (danielhb@linux.vnet.ibm.com) wrote: > > > On 12/14/2017 01:21 PM, Markus Armbruster wrote: > > Eric Blake <eblake@redhat.com> writes: > > > > > On 12/13/2017 12:15 PM, Daniel Henrique Barboza wrote: > > > > Commit 755f196898 ("qapi: Convert the cpu command") added the qmp_cpu > > > > function in qmp.c, leaving it blank. It the same commit, a working > > > > hmp_cpu was implemented. Since then, no further changes were made in > > > > qmp_cpu, resulting now in a working 'cpu' command that works in HMP > > > > and a 'cpu' command in QMP that does nothing. > > > > > > > > Regardless of what constraints were involved that time in not implemeting > > > > qmp_cpu, at this moment it is possible to have both. > > If I remember that part of history correctly, implementing the command > > in QMP was just as possible back then, but deemed a Bad Idea for the > > reason Eric explains below. > > > > What I don't quite remember is why we had to implement it in QMP as a > > no-op. Might have been due to the way QMP and HMP were entangled back > > then. > Speaking of QMP and HMP 'entanglement', is the content of the wiki > still valid? > > https://wiki.qemu.org/Features/QAPI > > And under "HMP Conversion" we have: > > "For HMP commands that don't have QMP equivalents today, new QMP functions > will be added to support these commands." > > This in particular gave me the motivation to go ahead and implement qmp_cpu. > But then again, the last entry on Status is "3/6/2011" so yeah, I should > have > asked here first whether the info from this wiki was relevant before sending > the patch. > > > > > This patch brings > > > > the logic of hmp_cpu to qmp_cpu and converts the HMP function to use its > > > > QMP counterpart. > > > I'm not sure I like this. HMP is stateful (you have to remember what > > > previous 'cpu' commands have been run to tell what the current command > > > will do). That may be convenient (if not confusing) to humans, but is > > > lousy for machine interfaces. QMP should be stateless as much as > > > possible - for any command that would behave differently according to > > > what CPU is selected, THAT command (and not a different 'cpu' command > > > executed previously) should have a cpu argument alongside all its other > > > parameters. > > > > > > So unless you have a really strong use case for this, I don't think we > > > want it. > > My case was simply "HMP has it, QMP doesn't". I wasn't aware that QMP > must be as stateless as possible but HMP can retain state. > > Now, is there any command that actually is impacted or makes use of the > current monitor CPU? I've searched a bit in qapi-schema.json and > hmp-commands.hx and haven't found any (although this does not > mean necessarily that no command is making use of it). Supposing > that no command makes good use of it, perhaps it's a good exercise > to evaluate if both qmp_cpu and hmp_cpu should be deprecated. I don't think there should be anything that uses it in qmp, there are in hmp - for example 'info registers' or 'info lapic' use the current cpu in HMP. Dave > > > > > > > > > > +++ b/qapi-schema.json > > > > @@ -1048,11 +1048,19 @@ > > > > ## > > > > # @cpu: > > > > # > > > > -# This command is a nop that is only provided for the purposes of compatibility. > > > > +# Set the default CPU. > > > > # > > > > -# Since: 0.14.0 > > > > +# @index: The index of the virtual CPU to be set as default > > > > +# > > > > +# Returns: Nothing on success > > > > +# > > > > +# Since: 2.12.0 > > > > +# > > > > +# Example: > > > > +# > > > > +# -> { "execute": "cpu", "arguments": { "index": 2 } } > > > > +# <- { "return": {} } > > > > # > > > > -# Notes: Do not use this command. > > > > ## > > > > { 'command': 'cpu', 'data': {'index': 'int'} } > > > > diff --git a/qmp.c b/qmp.c > > > > index e8c303116a..c482225d5c 100644 > > > > --- a/qmp.c > > > > +++ b/qmp.c > > > > @@ -115,7 +115,9 @@ void qmp_system_powerdown(Error **erp) > > > > void qmp_cpu(int64_t index, Error **errp) > > > > { > > > > - /* Just do nothing */ > > > > + if (monitor_set_cpu(index) < 0) { > > > > + error_setg(errp, "Invalid CPU index"); > > > > + } > > > > } > > > > void qmp_cpu_add(int64_t id, Error **errp) > > > > > > > Better yet, let's document that 'cpu' is deprecated, so that we can > > > remove it from QMP altogether in a couple of releases. > > Yes. > > > > The standard way to deprecate a feature is to add it to appendix > > "Deprecated features" in qemu-doc.texi, and make its use trigger > > suitable deprecation messages, pointing to a replacement if any. > > I'll give a try. > > > Daniel > > > > > Unfortunately, we still lack means to signal "X is deprecated, use Y > > instead" to a QMP client. Not important in this case, because the > > command has never worked. > > > -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Qemu-devel] [PATCH v1 1/2] qmp.c: (re)implement qmp_cpu 2017-12-15 18:59 ` Dr. David Alan Gilbert @ 2017-12-18 9:12 ` Markus Armbruster 0 siblings, 0 replies; 12+ messages in thread From: Markus Armbruster @ 2017-12-18 9:12 UTC (permalink / raw) To: Dr. David Alan Gilbert; +Cc: Daniel Henrique Barboza, qemu-devel "Dr. David Alan Gilbert" <dgilbert@redhat.com> writes: > * Daniel Henrique Barboza (danielhb@linux.vnet.ibm.com) wrote: >> >> >> On 12/14/2017 01:21 PM, Markus Armbruster wrote: >> > Eric Blake <eblake@redhat.com> writes: >> > >> > > On 12/13/2017 12:15 PM, Daniel Henrique Barboza wrote: >> > > > Commit 755f196898 ("qapi: Convert the cpu command") added the qmp_cpu >> > > > function in qmp.c, leaving it blank. It the same commit, a working >> > > > hmp_cpu was implemented. Since then, no further changes were made in >> > > > qmp_cpu, resulting now in a working 'cpu' command that works in HMP >> > > > and a 'cpu' command in QMP that does nothing. >> > > > >> > > > Regardless of what constraints were involved that time in not implemeting >> > > > qmp_cpu, at this moment it is possible to have both. >> > If I remember that part of history correctly, implementing the command >> > in QMP was just as possible back then, but deemed a Bad Idea for the >> > reason Eric explains below. >> > >> > What I don't quite remember is why we had to implement it in QMP as a >> > no-op. Might have been due to the way QMP and HMP were entangled back >> > then. >> Speaking of QMP and HMP 'entanglement', is the content of the wiki >> still valid? >> >> https://wiki.qemu.org/Features/QAPI >> >> And under "HMP Conversion" we have: >> >> "For HMP commands that don't have QMP equivalents today, new QMP functions >> will be added to support these commands." >> >> This in particular gave me the motivation to go ahead and implement qmp_cpu. >> But then again, the last entry on Status is "3/6/2011" so yeah, I should >> have >> asked here first whether the info from this wiki was relevant before sending >> the patch. >> >> > > > This patch brings >> > > > the logic of hmp_cpu to qmp_cpu and converts the HMP function to use its >> > > > QMP counterpart. >> > > I'm not sure I like this. HMP is stateful (you have to remember what >> > > previous 'cpu' commands have been run to tell what the current command >> > > will do). That may be convenient (if not confusing) to humans, but is >> > > lousy for machine interfaces. QMP should be stateless as much as >> > > possible - for any command that would behave differently according to >> > > what CPU is selected, THAT command (and not a different 'cpu' command >> > > executed previously) should have a cpu argument alongside all its other >> > > parameters. >> > > >> > > So unless you have a really strong use case for this, I don't think we >> > > want it. >> >> My case was simply "HMP has it, QMP doesn't". I wasn't aware that QMP >> must be as stateless as possible but HMP can retain state. >> >> Now, is there any command that actually is impacted or makes use of the >> current monitor CPU? I've searched a bit in qapi-schema.json and >> hmp-commands.hx and haven't found any (although this does not >> mean necessarily that no command is making use of it). Supposing >> that no command makes good use of it, perhaps it's a good exercise >> to evaluate if both qmp_cpu and hmp_cpu should be deprecated. > > I don't think there should be anything that uses it in qmp, there are in > hmp - for example 'info registers' or 'info lapic' use the current cpu > in HMP. Search for mon_get_cpu(). Any use in QMP would be a bug. ^ permalink raw reply [flat|nested] 12+ messages in thread
* [Qemu-devel] [PATCH v1 2/2] cpus.c: change qmp_query_cpus 'value->current' logic 2017-12-13 18:15 [Qemu-devel] [PATCH v1 0/2] QMP: implementing qmp_cpu Daniel Henrique Barboza 2017-12-13 18:15 ` [Qemu-devel] [PATCH v1 1/2] qmp.c: (re)implement qmp_cpu Daniel Henrique Barboza @ 2017-12-13 18:15 ` Daniel Henrique Barboza 2017-12-14 19:50 ` Daniel Henrique Barboza 1 sibling, 1 reply; 12+ messages in thread From: Daniel Henrique Barboza @ 2017-12-13 18:15 UTC (permalink / raw) To: qemu-devel; +Cc: dgilbert, armbru, Daniel Henrique Barboza qmp_query_cpus always return the same information, ignoring the monitor state. This means that information such as cpu->value->current will always return the same value ((cpu == first_cpu) at this moment). This function is used by hmp_info_cpus that does its own logic based on monitor_get_cpu_index() to print the current/active CPU information, ignoring cpu->value->current. This value is used as is in QMP query-cpus though. This wasn't a problem because QMP couldn't set its current CPU via qmp_cpu anyway, so query-cpus returning the same state all the time (regarding current CPU for the monitor) wasn't a problem. But now we can use qmp_cpu to set the current monitor CPU, making the return from query-cpus wrong. This patch makes a simple change in qmp_query_cpus to change the cpu->value->current logic to consider the current monitor state, like it was being done in hmp_info_cpus. Now, cpu->value->current will return an accurate value for both QMP and HMP calls. hmp_info_cpus can no use this value directly instead of doing its own logic. Signed-off-by: Daniel Henrique Barboza <danielhb@linux.vnet.ibm.com> --- cpus.c | 2 +- hmp.c | 6 +----- 2 files changed, 2 insertions(+), 6 deletions(-) diff --git a/cpus.c b/cpus.c index 114c29b6a0..d3b79d1c02 100644 --- a/cpus.c +++ b/cpus.c @@ -1919,7 +1919,7 @@ CpuInfoList *qmp_query_cpus(Error **errp) info = g_malloc0(sizeof(*info)); info->value = g_malloc0(sizeof(*info->value)); info->value->CPU = cpu->cpu_index; - info->value->current = (cpu == first_cpu); + info->value->current = (cpu->cpu_index == monitor_get_cpu_index()); info->value->halted = cpu->halted; info->value->qom_path = object_get_canonical_path(OBJECT(cpu)); info->value->thread_id = cpu->thread_id; diff --git a/hmp.c b/hmp.c index 7506f105a0..1259cafc1f 100644 --- a/hmp.c +++ b/hmp.c @@ -363,11 +363,7 @@ void hmp_info_cpus(Monitor *mon, const QDict *qdict) cpu_list = qmp_query_cpus(NULL); for (cpu = cpu_list; cpu; cpu = cpu->next) { - int active = ' '; - - if (cpu->value->CPU == monitor_get_cpu_index()) { - active = '*'; - } + int active = cpu->value->current ? '*' : ' '; monitor_printf(mon, "%c CPU #%" PRId64 ":", active, cpu->value->CPU); -- 2.13.6 ^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: [Qemu-devel] [PATCH v1 2/2] cpus.c: change qmp_query_cpus 'value->current' logic 2017-12-13 18:15 ` [Qemu-devel] [PATCH v1 2/2] cpus.c: change qmp_query_cpus 'value->current' logic Daniel Henrique Barboza @ 2017-12-14 19:50 ` Daniel Henrique Barboza 0 siblings, 0 replies; 12+ messages in thread From: Daniel Henrique Barboza @ 2017-12-14 19:50 UTC (permalink / raw) To: qemu-devel; +Cc: dgilbert, armbru On 12/13/2017 04:15 PM, Daniel Henrique Barboza wrote: > qmp_query_cpus always return the same information, ignoring the > monitor state. This means that information such as cpu->value->current > will always return the same value ((cpu == first_cpu) at this moment). > This function is used by hmp_info_cpus that does its own logic based on > monitor_get_cpu_index() to print the current/active CPU information, > ignoring cpu->value->current. This value is used as is in QMP > query-cpus though. > > This wasn't a problem because QMP couldn't set its current CPU via > qmp_cpu anyway, so query-cpus returning the same state all the time > (regarding current CPU for the monitor) wasn't a problem. But now > we can use qmp_cpu to set the current monitor CPU, making the return > from query-cpus wrong. > > This patch makes a simple change in qmp_query_cpus to change the > cpu->value->current logic to consider the current monitor state, > like it was being done in hmp_info_cpus. Now, cpu->value->current > will return an accurate value for both QMP and HMP calls. hmp_info_cpus > can no use this value directly instead of doing its own logic. > > Signed-off-by: Daniel Henrique Barboza <danielhb@linux.vnet.ibm.com> > --- The purpose of this patch watered away with qmp_cpu doing nothing. Although there is a point to be made that this might be "nicer" that what we have, a sort of cleanup, I am not sure if it's worth it. Apply it or leave it alone, either way works for me. Daniel > cpus.c | 2 +- > hmp.c | 6 +----- > 2 files changed, 2 insertions(+), 6 deletions(-) > > diff --git a/cpus.c b/cpus.c > index 114c29b6a0..d3b79d1c02 100644 > --- a/cpus.c > +++ b/cpus.c > @@ -1919,7 +1919,7 @@ CpuInfoList *qmp_query_cpus(Error **errp) > info = g_malloc0(sizeof(*info)); > info->value = g_malloc0(sizeof(*info->value)); > info->value->CPU = cpu->cpu_index; > - info->value->current = (cpu == first_cpu); > + info->value->current = (cpu->cpu_index == monitor_get_cpu_index()); > info->value->halted = cpu->halted; > info->value->qom_path = object_get_canonical_path(OBJECT(cpu)); > info->value->thread_id = cpu->thread_id; > diff --git a/hmp.c b/hmp.c > index 7506f105a0..1259cafc1f 100644 > --- a/hmp.c > +++ b/hmp.c > @@ -363,11 +363,7 @@ void hmp_info_cpus(Monitor *mon, const QDict *qdict) > cpu_list = qmp_query_cpus(NULL); > > for (cpu = cpu_list; cpu; cpu = cpu->next) { > - int active = ' '; > - > - if (cpu->value->CPU == monitor_get_cpu_index()) { > - active = '*'; > - } > + int active = cpu->value->current ? '*' : ' '; > > monitor_printf(mon, "%c CPU #%" PRId64 ":", active, cpu->value->CPU); > ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2017-12-18 9:20 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-12-13 18:15 [Qemu-devel] [PATCH v1 0/2] QMP: implementing qmp_cpu Daniel Henrique Barboza 2017-12-13 18:15 ` [Qemu-devel] [PATCH v1 1/2] qmp.c: (re)implement qmp_cpu Daniel Henrique Barboza 2017-12-14 2:18 ` Eric Blake 2017-12-14 15:21 ` Markus Armbruster 2017-12-14 19:46 ` Daniel Henrique Barboza 2017-12-15 13:56 ` Markus Armbruster 2017-12-15 18:11 ` Paolo Bonzini 2017-12-18 9:20 ` Markus Armbruster 2017-12-15 18:59 ` Dr. David Alan Gilbert 2017-12-18 9:12 ` Markus Armbruster 2017-12-13 18:15 ` [Qemu-devel] [PATCH v1 2/2] cpus.c: change qmp_query_cpus 'value->current' logic Daniel Henrique Barboza 2017-12-14 19:50 ` Daniel Henrique Barboza
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.