From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:34267) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QqNuY-00076j-Nt for qemu-devel@nongnu.org; Mon, 08 Aug 2011 07:22:23 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QqNuX-00050V-Jf for qemu-devel@nongnu.org; Mon, 08 Aug 2011 07:22:22 -0400 Received: from mx1.redhat.com ([209.132.183.28]:6694) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QqNuX-00050I-2j for qemu-devel@nongnu.org; Mon, 08 Aug 2011 07:22:21 -0400 Message-ID: <4E3FC6E6.1050202@redhat.com> Date: Mon, 08 Aug 2011 14:22:14 +0300 From: Avi Kivity MIME-Version: 1.0 References: <1312384643-581-1-git-send-email-lcapitulino@redhat.com> <1312384643-581-3-git-send-email-lcapitulino@redhat.com> <4E3A6C8C.8060304@redhat.com> <4E3A71D3.6030700@siemens.com> In-Reply-To: <4E3A71D3.6030700@siemens.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 2/7] Replace VMSTOP macros with a proper QemuState type List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: blauwirbel@gmail.com, amit.shah@redhat.com, aliguori@us.ibm.com, qemu-devel@nongnu.org, Luiz Capitulino On 08/04/2011 01:17 PM, Jan Kiszka wrote: > > > > Why "QemuState"? In general, "qemu" can be inferred from the fact that > > we're in qemu.git. Suggest "RunState". > > > > Second, these states can coexist. A user may pause the VM > > simultaneously with the watchdog firing or entering premigrate state. > > In fact, with multiple monitors, each monitor can pause and resume the > > vm independently. > > > > So I think we should keep a reference count instead of just a start/stop > > state. Perhaps > > > > vm_stop(QemuState s) > > { > > ++stopcount[s]; > > } > > > > vm_is_stopped() > > { > > for (s in states) > > if (stopcount[s]) > > return true; > > return false; > > } > > I don't think this makes sense nor is user-friendly. If one command > channel suspends the machine, others have the chance to subscribe for > that event. It's inherently racy. > Maintaining a suspension counter would mean you also need a > channel to query its value. Why? > IMHO, there is also no use for defining stopped orthogonally to > premigrate and other states that imply that the machine is stopped. > Basically they mean "stopped for/because of X". We just need to avoid > that you can enter plain stopped state from them by issuing the > corresponding monitor command. The other way around might be possible, > though, if there are race windows. > I'm worried about the following race: stop (qemu stopped for internal reason) stop comment processed resume The (qemu stopped for internal reason) part is lost. -- error compiling committee.c: too many arguments to function