Re: [Qemu-devel] [Qemu-stable] qmp commands get rejected

[mdroth <mdroth@linux.vnet.ibm.com>]

On Sat, May 25, 2013 at 01:09:50PM +0200, Stefan Priebe wrote:
> Am 25.05.2013 00:32, schrieb mdroth:
> >On Sat, May 25, 2013 at 12:12:22AM +0200, Stefan Priebe wrote:
> >>Am 25.05.2013 00:09, schrieb mdroth:
> >>>>>>>I would try to create a small example script.
> >>>>>>
> >>>>>>I use qmp-shell and other little scripts very often.
> >>>>>>
> >>>>>>>Am this be due to the fact that I don't wait for the welcome banner
> >>>>>>>right now?
> >>>>>>
> >>>>>>If you're not reading from the socket, then you'll get the banner back
> >>>>>>when
> >>>>>>you read your first response. But qom-set shouldn't fail because of that.
> >>>>
> >>>>I can workaround it by adding this patch:
> >>>>diff --git a/monitor.c b/monitor.c
> >>>>index 62aaebe..9997520 100644
> >>>>--- a/monitor.c
> >>>>+++ b/monitor.c
> >>>>@@ -4239,7 +4239,8 @@ static int monitor_can_read(void *opaque)
> >>>>  static int invalid_qmp_mode(const Monitor *mon, const char *cmd_name)
> >>>>  {
> >>>>      int is_cap = compare_cmd(cmd_name, "qmp_capabilities");
> >>>>-    return (qmp_cmd_mode(mon) ? is_cap : !is_cap);
> >>>>+//    return (qmp_cmd_mode(mon) ? is_cap : !is_cap);
> >>>>+    return ((is_cap > 0) ? 0 : (qmp_cmd_mode(mon) ? is_cap : !is_cap));
> >>>>  }
> >>>
> >>>I think this is unrelated to your original issue. If you issue
> >>>'qmp_capabilities' command more than once you will get CommandNotFound,
> >>>and that behavior seems to be present even with v1.3.0. This patch seems
> >>>to be masking the problem you're having (which seems to be state from
> >>>previous monitor sessions/connections leaking into subsequent ones).
> >>
> >>That sounds reasonable. I'm using proxmox / PVE which does a lot of
> >>qmp queries in the background. So i might see situations where X
> >>connections in parallel do qmp queries.
> >>
> >>>It's possible the GSource-based mechanism for handling I/O for chardev
> >>>backends is causing a difference in behavior. Still not sure exactly
> >>>what's going on though.
> >>Can i revert some patches to test?
> >
> >I think somewhere prior to this one should be enough to test:
> >
> >2ea5a7af7bfa576a5936400ccca4144caca9640b
> 
> YES! I used 2ea5a7af7bfa576a5936400ccca4144caca9640b~1 for my tests
> and this works absoluty fine.

Turns out the real culprit was a few commits later:

9f939df955a4152aad69a19a77e0898631bb2c18

I've sent a workaround this fixes things for QMP, but we may need a more
general fix. Please give it a shot and see if it fixes your issues:

http://article.gmane.org/gmane.comp.emulators.qemu/213106

> 
> Stefan
>