[Qemu-devel] [PATCH v1 0/2] QMP: implementing qmp_cpu

[Qemu-devel] [PATCH v1 0/2] QMP: implementing qmp_cpu

[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

[Qemu-devel] [PATCH v1 1/2] qmp.c: (re)implement qmp_cpu

[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

Re: [Qemu-devel] [PATCH v1 1/2] qmp.c: (re)implement qmp_cpu

[Eric Blake]

[-- 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 --]

Re: [Qemu-devel] [PATCH v1 1/2] qmp.c: (re)implement qmp_cpu

[Markus Armbruster]

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.

Re: [Qemu-devel] [PATCH v1 1/2] qmp.c: (re)implement qmp_cpu

[Daniel Henrique Barboza]

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.
>

Re: [Qemu-devel] [PATCH v1 1/2] qmp.c: (re)implement qmp_cpu

[Markus Armbruster]

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.

[...]

Re: [Qemu-devel] [PATCH v1 1/2] qmp.c: (re)implement qmp_cpu

[Paolo Bonzini]

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

Re: [Qemu-devel] [PATCH v1 1/2] qmp.c: (re)implement qmp_cpu

[Markus Armbruster]

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.

Re: [Qemu-devel] [PATCH v1 1/2] qmp.c: (re)implement qmp_cpu

[Dr. David Alan Gilbert]

* 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

Re: [Qemu-devel] [PATCH v1 1/2] qmp.c: (re)implement qmp_cpu

[Markus Armbruster]

"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.

[Qemu-devel] [PATCH v1 2/2] cpus.c: change qmp_query_cpus 'value->current' logic

[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

Re: [Qemu-devel] [PATCH v1 2/2] cpus.c: change qmp_query_cpus 'value->current' logic

[Daniel Henrique Barboza]

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);
>