On Mon, 08 Aug 2011 14:22:14 +0300
Avi Kivity <a...@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.
