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?
