From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([140.186.70.92]:46757)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <lcapitulino@redhat.com>) id 1QqPpU-000592-GY
	for qemu-devel@nongnu.org; Mon, 08 Aug 2011 09:25:17 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <lcapitulino@redhat.com>) id 1QqPpT-0005Aj-DS
	for qemu-devel@nongnu.org; Mon, 08 Aug 2011 09:25:16 -0400
Received: from mx1.redhat.com ([209.132.183.28]:40624)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <lcapitulino@redhat.com>) id 1QqPpT-0005Ad-6X
	for qemu-devel@nongnu.org; Mon, 08 Aug 2011 09:25:15 -0400
Date: Mon, 8 Aug 2011 10:25:10 -0300
From: Luiz Capitulino <lcapitulino@redhat.com>
Message-ID: <20110808102510.6d315297@doriath>
In-Reply-To: <4E3FC6E6.1050202@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>
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: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Avi Kivity <avi@redhat.com>
Cc: blauwirbel@gmail.com, Jan Kiszka <jan.kiszka@siemens.com>, aliguori@us.ibm.com, amit.shah@redhat.com, qemu-devel@nongnu.org

On Mon, 08 Aug 2011 14:22:14 +0300
Avi Kivity <avi@redhat.com> wrote:

> 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.

If the "stop" you're referring to happens through vm_stop(), then no,
it won't be lost because do_vm_stop() doesn't allow qemu to be stopped
twice.