[Qemu-devel] Two QMP events issues

[Luiz Capitulino]

 Hi there,

 I have two not so related QMP events issues two discuss, but I will talk about
them in the same email to avoid starting two threads.

 The first problem is wrt the STOP event. Right now it's only emitted if it's
triggered through qemu_system_vmstop_request(), which afaik will only be
called if CONFIG_IOTHREAD is enabled (nonsense, yes).

 The best fix I can think of is to move the STOP event down to do_vm_stop().
We could even have a 'reason' data member with the string representation of
the EXCP_ macros. Looks like this is the right thing do to.

 There's a problem, though. Migration and block subsystems also do vm_stop(0).
The former's reason seems to be 'stop to be loaded' and the latter is 'can't
continue' on disk errors. Note that the block subsystem already has its own
event for disk errors.

 So, my solution is to not generate the STOP event on vm_stop(0). If any
vm_stop(0) user (eg. migration) wants to generate events they should create
the appropriate EXCP_ macro for that.

 Does this look good?

 The second problem is about the watchdog device. I have been asked to
add events for the watchdog's device actions (see
hw/watchdog.c:watchdog_perform_action()).

 Issue is: most of those events directly map to QEMU's events already
generated by QMP, such as RESET, SHUTDOWN, POWEROFF etc.

 We have two solutions:

1. Introduce watchdog's own events. This is easy to do, but will
generate two QMP events for most actions. Eg. the watchdog's WDT_RESET
action will generate a QMP event for WDT_RESET and will generate
another RESET event when this action takes place in QEMU

2. Add a 'source' data member to all events requested via the
qemu_system_* functions, so that we can have a 'wachtdog' source and
only one event is triggered. This will require a more complex change
and maybe some hacks will be needed (eg. for vm_stop())

 Opinions?