From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MJ3eE-0001Eq-8L for qemu-devel@nongnu.org; Tue, 23 Jun 2009 06:54:42 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MJ3e8-0001CP-5y for qemu-devel@nongnu.org; Tue, 23 Jun 2009 06:54:41 -0400 Received: from [199.232.76.173] (port=55136 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MJ3e7-0001C7-64 for qemu-devel@nongnu.org; Tue, 23 Jun 2009 06:54:35 -0400 Received: from mx20.gnu.org ([199.232.41.8]:2205) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MJ3e6-0000OG-Op for qemu-devel@nongnu.org; Tue, 23 Jun 2009 06:54:34 -0400 Received: from lizzard.sbs.de ([194.138.37.39]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MJ3e5-0005gv-Ss for qemu-devel@nongnu.org; Tue, 23 Jun 2009 06:54:34 -0400 Message-ID: <4A40B467.7000604@siemens.com> Date: Tue, 23 Jun 2009 12:54:31 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <20090623013005.39e27923@doriath> <4A409A4D.8030605@siemens.com> <20090623100428.GD6881@redhat.com> <4A40AA3D.2050807@siemens.com> <4A40AB9D.6040204@redhat.com> In-Reply-To: <4A40AB9D.6040204@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 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: Avi Kivity Cc: aliguori@us.ibm.com, ehabkost@redhat.com, dlaor@redhat.com, qemu-devel@nongnu.org, Luiz Capitulino Avi Kivity wrote: > On 06/23/2009 01:11 PM, Jan Kiszka wrote: >>> If we support multiple monitors, it might be desirable to allow the >>> app owning the main 'control' monitor channel to be able to indicate >>> that additional monitor channels are read-only. eg, so libvirt could >>> allow the user to connect to the monitor to run 'info' commands for >>> debug support without risk of having state changed behind its back >>> >> >> Couldn't libvirt deal with update given we provide them as events? >> Otherwise, your suggestion makes sense, definitely as long as it would >> wreck libvirt's internal house keeping or for commands that are not >> synchronizable. >> > > It would be a nightmare, consider both libvirt and a user hotplugging > something into the same pci slot, or a user starting migration, or > quitting, or ... Migration, yes, but hot-plugging is resolvable - given config update events. > > Having -monitor readonly makes sense. But not for all features, only those libvirt is capable to handle (I think there are quite a few qemu specifics libvirt does not bother about) and only as long as there is no proper synchronization. Again, migration and save/restore will continue to require exclusive access, but the rest is just a question of proper synchronization IMHO. See, I don't want to kill my management app just because I attached to a guest via gdb and start injecting reconfiguration events for testing purposes (e.g. attach/detach a USB device for which I develop a driver). Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux