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
