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