From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:45664) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UghvJ-00025v-A8 for qemu-devel@nongnu.org; Sun, 26 May 2013 16:52:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UghvE-00061n-6K for qemu-devel@nongnu.org; Sun, 26 May 2013 16:52:13 -0400 Received: from mail-ph.de-nserver.de ([85.158.179.214]:42639) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UghvD-00060N-SE for qemu-devel@nongnu.org; Sun, 26 May 2013 16:52:08 -0400 Message-ID: <51A275F9.3070505@profihost.ag> Date: Sun, 26 May 2013 22:52:09 +0200 From: Stefan Priebe MIME-Version: 1.0 References: <20130524112152.32ce478a@redhat.com> <519FC9C3.7070803@profihost.ag> <519FDDAA.4010801@profihost.ag> <20130524220909.GA6241@vm> <519FE5C6.5070509@profihost.ag> <20130524223217.GB6241@vm> <51A09BFE.4020003@profihost.ag> <20130526012317.GB1577@vm> <51A226A0.2080708@profihost.ag> <20130526153648.GB4599@vm> In-Reply-To: <20130526153648.GB4599@vm> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [Qemu-stable] qmp commands get rejected List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: mdroth Cc: aliguori@us.ibm.com, Luiz Capitulino , "qemu-stable@nongnu.org" , Dietmar Maurer , qemu-devel Am 26.05.2013 17:36, schrieb mdroth: > On Sun, May 26, 2013 at 05:13:36PM +0200, Stefan Priebe wrote: >> Am 26.05.2013 03:23, schrieb mdroth: >>> 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 >> >> no i got again: >> The command qom-set has not been found JSON Reply: {"id": >> "21677:2", "error": {"class": "CommandNotFound", "desc": "The >> command qom-set has not been found"}} JSON Query: {"execute":"qom-set","id":"21677:2","arguments":{"value":2,"path":"machine/peripheral/balloon0","property":"guest-stats-polling-interval"}} >> at /usr/share/perl5/PVE/QMPClient.pm line 101. > > Darn, I noticed another potential race after I sent the patch. Hadn't > been able to trigger it on my end, but it might be what you're hitting. > > Just sent a v2, can you give that a shot? > > http://article.gmane.org/gmane.comp.emulators.qemu/213147 Thanks! This one works fine. Stefan