From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MJ5O3-0004fB-QZ for qemu-devel@nongnu.org; Tue, 23 Jun 2009 08:46:07 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MJ5Nz-0004dW-8e for qemu-devel@nongnu.org; Tue, 23 Jun 2009 08:46:07 -0400 Received: from [199.232.76.173] (port=40437 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MJ5Nz-0004dO-3k for qemu-devel@nongnu.org; Tue, 23 Jun 2009 08:46:03 -0400 Received: from mx2.redhat.com ([66.187.237.31]:59575) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MJ5Ny-0006bw-Aa for qemu-devel@nongnu.org; Tue, 23 Jun 2009 08:46:02 -0400 Message-ID: <4A40CEBF.2030602@redhat.com> Date: Tue, 23 Jun 2009 15:46:55 +0300 From: Avi Kivity MIME-Version: 1.0 References: <20090623013005.39e27923@doriath> <4A409A4D.8030605@siemens.com> <20090623100428.GD6881@redhat.com> <4A40AA3D.2050807@siemens.com> <4A40AB9D.6040204@redhat.com> <4A40B467.7000604@siemens.com> <4A40BC66.8040206@redhat.com> <4A40C01C.2070004@siemens.com> <4A40C1B6.8080103@redhat.com> <4A40C248.8090801@siemens.com> <4A40C424.9040204@redhat.com> <4A40CCEC.7020208@siemens.com> In-Reply-To: <4A40CCEC.7020208@siemens.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH 11/11] QMP: Command-line flag to enable control mode List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: aliguori@us.ibm.com, ehabkost@redhat.com, dlaor@redhat.com, qemu-devel@nongnu.org, Luiz Capitulino On 06/23/2009 03:39 PM, Jan Kiszka wrote: > Avi Kivity wrote: > >> On 06/23/2009 02:53 PM, Jan Kiszka wrote: >> >>>>> I'm talking about, just as one example, sitting in front of my gdb >>>>> [frontend], doing guest kernel [driver] debugging and issuing "monitor >>>>> whatever" commands from one place, ie. not having to switch between >>>>> management app and debugging interface back and forth. >>>>> >>>>> >>>>> >>>> Can gdb issue monitor commands? >>>> >>>> >>> Yes. >>> >>> >> How does one do that? seems a very useful feature. >> > > By spawning an additional monitor terminal, but switching off its > readline support (as that is handled by gdb). > > In case there is still someone out there not being aware of this ;) : we > _do_ have support for multiple monitors in qemu already. Just try > "-monitor X -serial mon:Y" with X!=Y. > > >> I could say that management can proxy the gdb packets and thus support >> its own cli (in fact, it must if it wants to support live migration), >> but that's really an edge case and I doubt anyone will do that, so you >> have a good point. >> > > Proxying would mean interpreting all "classic" monitor commands to catch > those that may interfere with the mgmt app state. I also don't think > that is worth the effort. > No, you would use the management system's cli which naturally enforces all of a user's permissions and is integrated with the GUI: gui ----\ cli ----+---[ management server ] ---- [ libvirt ] ---- qemu gdb ----/ That's the only setup that can support migration without dropping sessions. That doesn't change the "I don't think it's worth the effort" state though. -- error compiling committee.c: too many arguments to function