qemu-stable
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: mdroth
Subject: Re: [Qemu-stable] [Qemu-devel] qmp commands get rejected
Date: Fri, 24 May 2013 17:09:09 -0500
User-agent: Mutt/1.5.21 (2010-09-15)

On Fri, May 24, 2013 at 11:37:46PM +0200, Stefan Priebe wrote:
> >Am 24.05.2013 17:21, schrieb Luiz Capitulino:
> >>On Fri, 24 May 2013 16:36:26 +0200
> >>Stefan Priebe - Profihost AG <address@hidden> wrote:
> >>
> >>>Am 24.05.2013 um 16:02 schrieb Luiz Capitulino <address@hidden>:
> >>>
> >>>>On Fri, 24 May 2013 15:57:59 +0200
> >>>>Stefan Priebe - Profihost AG <address@hidden> wrote:
> >>>>
> >>>>>Am 24.05.2013 um 15:23 schrieb Luiz Capitulino
> >>>>><address@hidden>:
> >>>>>
> >>>>>>On Fri, 24 May 2013 07:50:33 +0200
> >>>>>>Stefan Priebe <address@hidden> wrote:
> >>>>>>
> >>>>>>>Hello list,
> >>>>>>>
> >>>>>>>since upgrading from qemu 1.4.1 to 1.5.0 i've problems with qmp
> >>>>>>>commands.
> >>>>>>>
> >>>>>>>With Qemu 1.5 i've the following socket communication:
> >>>>>>>
> >>>>>>>'{"execute":"qmp_capabilities","id":"12125:1","arguments":{}}'
> >>>>>>>
> >>>>>>>'{"return": {}, "id": "12125:1"}'
> >>>>>>>
> >>>>>>>'{"execute":"qom-set","id":"12125:2","arguments":{"value":2,"path":"machine/peripheral/balloon0","property":"guest-stats-polling-interval"}}'
> >>>>>>>
> >>>>>>>
> >>>>>>>'{"QMP": {"version": {"qemu": {"micro": 0, "minor": 5, "major": 1},
> >>>>>>>"package": ""}, "capabilities": []}}'
> >>>>>>>
> >>>>>>>'{"id": "12125:2", "error": {"class": "CommandNotFound", "desc":
> >>>>>>>"The
> >>>>>>>command qom-set has not been found"}}'
> >>>>>>>
> >>>>>>>
> >>>>>>>It seems that the command mode (qmp_capabilities) gets resets by the
> >>>>>>>welcome banner?
> >>>>>>
> >>>>>>It looks like you got disconnected before qom-set was issued.
> >>>>>
> >>>>>No its the same socket connection. No disconnect had happened.
> >>>>>
> >>>>>>
> >>>>>>Can you share more details on how those commands are being issued?
> >>>>>
> >>>>>They're send through socket with a perl script. What do you need?
> >>>>
> >>>>That perl script maybe? I can't reproduce the problem.
> >>>
> >>>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).

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.

> 
>  /*
> 
> Stefan
> 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]