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

[Stefan Priebe <s.priebe@profihost.ag>]

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.

Stefan