From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NeTsE-0006Q8-7A for qemu-devel@nongnu.org; Mon, 08 Feb 2010 08:41:58 -0500 Received: from [199.232.76.173] (port=42784 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NeTsD-0006Pq-Rz for qemu-devel@nongnu.org; Mon, 08 Feb 2010 08:41:57 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1NeTsC-0005mx-16 for qemu-devel@nongnu.org; Mon, 08 Feb 2010 08:41:57 -0500 Received: from mx1.redhat.com ([209.132.183.28]:26182) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NeTsB-0005md-F9 for qemu-devel@nongnu.org; Mon, 08 Feb 2010 08:41:55 -0500 Date: Mon, 8 Feb 2010 11:41:45 -0200 From: Luiz Capitulino Message-ID: <20100208114145.4bd64349@doriath> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Two QMP events issues List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: aliguori@us.ibm.com, armbru@redhat.com 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?