From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:43802) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QqQTP-0007uZ-4E for qemu-devel@nongnu.org; Mon, 08 Aug 2011 10:06:32 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QqQTO-0004lH-2C for qemu-devel@nongnu.org; Mon, 08 Aug 2011 10:06:31 -0400 Received: from mx1.redhat.com ([209.132.183.28]:62405) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QqQTN-0004l5-RS for qemu-devel@nongnu.org; Mon, 08 Aug 2011 10:06:30 -0400 Date: Mon, 8 Aug 2011 11:06:25 -0300 From: Luiz Capitulino Message-ID: <20110808110625.2f96a8e0@doriath> In-Reply-To: <4E3FEA88.7040407@redhat.com> 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> <4E3FC6E6.1050202@redhat.com> <20110808102510.6d315297@doriath> <4E3FE429.4010509@redhat.com> <20110808102858.54ab1b55@doriath> <4E3FE741.7060302@redhat.com> <20110808104714.6d8aeea4@doriath> <4E3FEA88.7040407@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII 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: Avi Kivity Cc: blauwirbel@gmail.com, Jan Kiszka , aliguori@us.ibm.com, amit.shah@redhat.com, qemu-devel@nongnu.org On Mon, 08 Aug 2011 16:54:16 +0300 Avi Kivity wrote: > On 08/08/2011 04:47 PM, Luiz Capitulino wrote: > > > > > > Well, then, the user won't know something happened and will happily > > > resume the guest, like I outlined above. > > > > I think it makes sense to return an error in the monitor if the user > > tries to stop qemu when it's already stopped. Not sure if it will do what you > > think it should do, but we should always tell the user when we're unable to > > carry his/her orders. > > > > But it does make sense to me to not allow stopping twice. First because it > > doesn't make sense to stop something which is not moving and second because > > what else can stop the vm if it's already stopped? > > > > Maybe vm_stop() should return an error, but I think this goes beyond this > > series. > > > > This is why I suggested a reference count. In this case, we can always > stop the guest "twice", because we don't lost information when we resume. I could give it a try in the near future, as I really think it's independent from this series, but I still don't understand what can stop an already stopped VM besides the user. This is a real question, is it really possible? If only the user can do that, then the refcount is overkill as just returning an error will do it.