From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Lcdpe-000836-7W for qemu-devel@nongnu.org; Thu, 26 Feb 2009 05:51:10 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Lcdpc-00082K-J4 for qemu-devel@nongnu.org; Thu, 26 Feb 2009 05:51:09 -0500 Received: from [199.232.76.173] (port=43335 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Lcdpc-00082F-7p for qemu-devel@nongnu.org; Thu, 26 Feb 2009 05:51:08 -0500 Received: from mx1.redhat.com ([66.187.233.31]:59979) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Lcdpb-0004Mt-Nm for qemu-devel@nongnu.org; Thu, 26 Feb 2009 05:51:07 -0500 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id n1QAp6ic000506 for ; Thu, 26 Feb 2009 05:51:06 -0500 Received: from file.fab.redhat.com (file.fab.redhat.com [10.33.63.6]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n1QAp7BL022560 for ; Thu, 26 Feb 2009 05:51:07 -0500 Received: from file.fab.redhat.com (localhost.localdomain [127.0.0.1]) by file.fab.redhat.com (8.13.1/8.13.1) with ESMTP id n1QAp6uP001154 for ; Thu, 26 Feb 2009 10:51:06 GMT Received: (from berrange@localhost) by file.fab.redhat.com (8.13.1/8.13.1/Submit) id n1QAp6bw001124 for qemu-devel@nongnu.org; Thu, 26 Feb 2009 10:51:06 GMT Date: Thu, 26 Feb 2009 10:51:06 +0000 From: "Daniel P. Berrange" Subject: Re: [Qemu-devel] Hardware watchdogs (patch for discussion only) Message-ID: <20090226105106.GD22494@redhat.com> References: <20090225233718.GA15750@amd.home.annexia.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090225233718.GA15750@amd.home.annexia.org> Reply-To: "Daniel P. Berrange" , qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org On Wed, Feb 25, 2009 at 11:37:18PM +0000, Richard W.M. Jones wrote: > Hi: > > I want to share an unfinished patch with the list just to make sure > that I'm heading in the right direction. > > This patch aims to implement a virtual hardware watchdog device. A > hardware watchdog in a real machine is a device that must be tickled > periodically by a userspace process to prove that the machine's > userspace is (in some sense) "alive". If the device isn't tickled > then after some timeout, it reboots the machine. > > These devices are generally very simple. I picked two devices to > emulate: the IBase 700, which is almost trivial, an ISA port to enable > and set the timeout, and another ISA port to disable. And the Intel > 6300ESB, a PCI device which represents a mid-high end range of > features and is very well documented. Both have clean Linux device > drivers: > > http://lxr.linux.no/linux+v2.6.28.5/drivers/watchdog/ib700wdt.c > http://lxr.linux.no/linux+v2.6.28.5/drivers/watchdog/i6300esb.c > > (Both also come with Windows drivers which I haven't tested) > A quick note WRT the possible actions > @@ -4072,6 +4073,8 @@ > "-old-param old param mode\n" > #endif > "-tb-size n set TB size\n" > + "-watchdog ib700|i6300esb[,action=reboot|shutdown|pause|exit]\n" > + " enable virtual hardware watchdog [default=none]\n" > "-incoming p prepare for incoming migration, listen on port p\n" > "\n" > "During emulation, the following keys are useful:\n" > +/* This actually performs the "action" once a watchdog has expired, > + * ie. reboot, shutdown, exit, etc. > + */ > +void > +watchdog_perform_action (int action) > +{ > + fprintf (stderr, "qemu: watchdog %s!\n", string_of_action (action)); > + > + switch (action) { > + case WDT_REBOOT: > + qemu_system_reset (); > + break; This one shouldn't be called directly. qemu_system_reset_request() sets a flag to interrupt the CPU, and then the main loop when seeing the flag set, will call qemu_system_reset(). It also doesn't actally do a reboot. It hard resets the CPU and devices. The guest OS doesn't do a controlled shutdown. > + case WDT_REBOOTNICE: > + qemu_system_reset_request (); > + break; > + > + case WDT_SHUTDOWN: > + qemu_system_powerdown (); > + break; Likewise here - this is called indirectly by the main loop after qemu_system_powerdown_request() sets the powerdown flag. > + case WDT_SHUTDOWNNICE: > + qemu_system_powerdown_request (); > + break; > + > + case WDT_PAUSE: > + vm_stop (0); > + break; > + > + case WDT_EXIT: > + exit (0); > + } > +} > + > +The @var{action} controls what QEMU will do when the timer expires. > +The default is > +@code{reboot} (forcefully reboot the guest). > +Other possible actions are: > +@code{rebootnice} (attempt to gracefully reboot the guest). > +@code{shutdown} (forcefully shutdown the guest), > +@code{shutdownnice} (attempt to gracefully shutdown the guest), > +@code{pause} (pause the guest), or > +@code{exit} (immediately exit the QEMU process). I think we can only support the following options - shutdown - graceful shutdown of guest via ACPI event via qemu_system_powerdown_request() - poweroff - hard immediate power off of guest machine via qemu_system_shutdown_request() - reset - hard reset of the guest machine via qemu_system_reset_request() - pause - stop the guest CPU(s) Don't think we ned an 'exit' event, because I believe 'poweroff' should cause the emulator to exit Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|