From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MJ9AF-0001Fc-HB for qemu-devel@nongnu.org; Tue, 23 Jun 2009 12:48:07 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MJ9AB-0001Dg-Sg for qemu-devel@nongnu.org; Tue, 23 Jun 2009 12:48:07 -0400 Received: from [199.232.76.173] (port=38446 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MJ9AB-0001DZ-LJ for qemu-devel@nongnu.org; Tue, 23 Jun 2009 12:48:03 -0400 Received: from mx1.redhat.com ([66.187.233.31]:33030) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MJ9AB-0004i2-5Y for qemu-devel@nongnu.org; Tue, 23 Jun 2009 12:48:03 -0400 Date: Tue, 23 Jun 2009 17:47:56 +0100 From: "Daniel P. Berrange" Message-ID: <20090623164756.GC10690@redhat.com> References: <20090623012911.16b8c4d5@doriath> <20090623103251.GH6881@redhat.com> <20090623103616.409b716a@doriath> <20090623134851.GC6462@blackpad> <4A40DDE1.7070207@siemens.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A40DDE1.7070207@siemens.com> Subject: [Qemu-devel] Re: [PATCH 06/11] QMP: Introduce asynchronous events infrastructure Reply-To: "Daniel P. Berrange" List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: aliguori@us.ibm.com, dlaor@redhat.com, avi@redhat.com, qemu-devel@nongnu.org, Luiz Capitulino On Tue, Jun 23, 2009 at 03:51:29PM +0200, Jan Kiszka wrote: > Eduardo Habkost wrote: > > On Tue, Jun 23, 2009 at 10:36:16AM -0300, Luiz Capitulino wrote: > >> On Tue, 23 Jun 2009 11:32:51 +0100 > >> "Daniel P. Berrange" wrote: > >> > >>>> + > >>> If a client is not reading from the monitor channel quickly enough, then > >>> would this cause QEMU to block once the FD buffer is full ? A QEMU level > >>> buffer might give more leyway, but we don't want to grow unbounded, so > >>> ultimately we'll end up having to drop events. At which point you'd want > >>> to send an event to the client indicating that the event queue overflowed, > >>> so it can take remedial action to re-sync its state. > >> Wouldn't a buffer flush right at the beginning of this function solve this? > >> At least for QEMU? > > > > No, if the messages aren't being consumed fast enough by the other side. > > If the consumer isn't consuming the messages fast enough, we would need > > to either drop messages or block on the channel (that's the code code > > above would do: block on write()). > > > > I agree with Avi: if the system is so busy that the client doesn't > > consume the monitor messages fast enough, we are already screwed. > > Can't mgmt app and qemu also run on different hosts? If you happened to run the monitor using a TCP backend, then yes the mgmt app could be remote. This would be just insane though, since there's no security there whatsoever. I don't think the QEMU monitor wants to be in the business of encrypting, authenticating & authorizing monitor clients. Rather it should just be local only, and any mgmt tool using QEMU can provide secure remote mgmt transports at a higher level. Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|