On 2011-08-04 12:17, Jan Kiszka wrote:
> On 2011-08-04 11:55, Avi Kivity wrote:
>> On 08/03/2011 06:17 PM, Luiz Capitulino wrote:
>>> @@ -9,6 +9,20 @@
>>> #include "notify.h"
>>>
>>> /* vl.c */
>>> +
>>> +typedef enum {
>>> + QSTATE_DEBUG, /* qemu is running under gdb */
>>> + QSTATE_INTERROR, /* paused due to an internal error */
>>> + QSTATE_IOERROR, /* paused due to an I/O error */
>>> + QSTATE_PAUSED, /* paused by the user (ie. the 'stop'
>>> command) */
>>> + QSTATE_PREMIGRATE, /* paused preparing to finish migrate */
>>> + QSTATE_RESTVM, /* paused restoring the VM state */
>>> + QSTATE_RUNNING, /* qemu is running */
>>> + QSTATE_SAVEVM, /* paused saving VM state */
>>> + QSTATE_SHUTDOWN, /* guest shut down and -no-shutdown is in
>>> use */
>>> + QSTATE_WATCHDOG /* watchdog fired and qemu is configured to
>>> pause */
>>> +} QemuState;
>>> +
>>> extern const char *bios_name;
>>>
>>
>> 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. Maintaining a suspension counter would mean you also need a
> channel to query its value.
>
> 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.
The makes me wonder if qemu_state_set shouldn't validate if the state
transition is legal (simple switch/case). That way, we would have a
central point and could also avoid potential races or logical bugs where
a newly set state is accidentally overwritten due to unexpected
execution order.
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
