From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Lrv6s-0008O7-9Q for qemu-devel@nongnu.org; Thu, 09 Apr 2009 10:20:06 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Lrv6n-0008Hu-IQ for qemu-devel@nongnu.org; Thu, 09 Apr 2009 10:20:05 -0400 Received: from [199.232.76.173] (port=40883 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Lrv6m-0008HT-PK for qemu-devel@nongnu.org; Thu, 09 Apr 2009 10:20:01 -0400 Received: from lizzard.sbs.de ([194.138.37.39]:23475) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Lrv6m-0006Mn-6T for qemu-devel@nongnu.org; Thu, 09 Apr 2009 10:20:00 -0400 Message-ID: <49DE040B.5060107@siemens.com> Date: Thu, 09 Apr 2009 16:19:55 +0200 From: Jan Kiszka MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 2/6] Introduce monitor 'wait' command (v2) References: <1239215702-23818-1-git-send-email-aliguori@us.ibm.com> <1239215702-23818-2-git-send-email-aliguori@us.ibm.com> <49DDD57F.7000807@redhat.com> <49DDFAC6.6070708@us.ibm.com> <49DDFEEC.6050704@redhat.com> In-Reply-To: <49DDFEEC.6050704@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: libvir-list@redhat.com, Anthony Liguori , qemu-devel@nongnu.org, Hollis Blanchard Avi Kivity wrote: > Anthony Liguori wrote: >> Avi Kivity wrote: >>> Anthony Liguori wrote: >>>> The wait command will pause the monitor the command was issued in >>>> until a new >>>> event becomes available. Events are queued if there isn't a waiter >>>> present. >>>> The wait command completes after a single event is available. >>>> >>> >>> How do you stop a wait if there are no pending events? >> >> You mean, cancel a wait? You cannot. I thought about whether it was >> a problem or not. I'm not sure. > > A management agent might want to detach from guests, upgrade, restart, > and reattach. > >> >> You could introduce a wait-cancel command, but then you need a way to >> identify which wait you want to cancel. I can't think of a simple way >> to do that today. > > This, as well as the queueing that's necessary with this model, > indicates (to me) that it is too complicated. It should be feasible to handle some key sequence like ^C while the monitor is suspended (ie. blocked on things like event-wait or migrate). I thought about such a feature while reworking the involved parts but postponed it as I saw no urgent need for it. > >> >>>> Today, we queue events indefinitely but in the future, I suspect >>>> we'll drop >>>> events that are older than a certain amount of time to avoid infinitely >>>> allocating memory for long running VMs. >>>> >>> >>> This queueing plug the race where an event happens immediately after >>> a wait completes. But it could be avoided completely by having >>> asynchronous notifications on a single monitor. >> >> There are multiple things I think are being confused: asynchronous >> completion of monitor commands, events, monitor multiplexing, and >> non-human mode. >> >> There can only be one command active at any given time on a Monitor >> context. We can have many Monitor contexts. There is currently only >> one Monitor context connected to a character device at a given time. > > Don't think of 'migrate -d' as a command to perform migration, instead > it's a command to start migration. > > I also object to exposing internal qemu implementation details like > monitor contexts to the user (by forcing them to have multiple > connections). If we can't have more than one monitor command, we need > to fix that. > >> >> I think what you want to see is something like this: >> >> tag=4: info cpus >> tag=5: info kvm >> tag=5,rc=0: kvm enabled >> tag=4,rc=0: eip = 0x0000000444 >> rc=0,class=vm-state,name=start: vm started >> >> To me, this is a combination of events, which is introduced by this >> patch, a non-human monitor mode, and finally multiplexing multiple >> monitors into a single session. >> >> Right now, you can have the same functional thing by having three >> monitors. In the first monitor you'd see: >> >> (qemu) info cpus >> eip = 0x000000444 >> (qemu) >> >> In the second you'd see: >> >> (qemu) info kvm >> kvm enabled >> (qemu) >> >> In the third you'd see: >> >> (qemu) wait >> 23423423.23423: vm-state: start: vm started >> (qemu) >> >> Even those the two info commands today are synchronous, there's >> nothing requiring them to be (see migrate as an example). So I think >> we're in agreement but you just want to jump ahead 6 months ;-) >> > > Commands which are inherently synchronous should remain so. Commands > which are inherently async should be coded like that. It was a mistake > IMO to have 'migrate' be a synchronous command, it should have always > behaved as if -d is given. > > Having tagged replies is a good idea, but IMO, introducing multiple > monitors will create a lot of subtle problems, several of which we've > already identified. We do have multiple monitors already, try '-monitor X -serial mon:Y', or also attach via gdb and issue 'monitor whatever'. And we should continue to design the monitor interface for this (which means here: event notification should be configured per monitor session). Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux