Re: [Qemu-devel] [PATCH 2/7] Replace VMSTOP macros with a proper QemuState type

[Avi Kivity <avi@redhat.com>]

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