qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Daniel P. Berrange" <berrange@redhat.com>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Hardware watchdogs (patch for discussion only)
Date: Thu, 26 Feb 2009 10:51:06 +0000	[thread overview]
Message-ID: <20090226105106.GD22494@redhat.com> (raw)
In-Reply-To: <20090225233718.GA15750@amd.home.annexia.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 :|

  reply	other threads:[~2009-02-26 10:51 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-25 23:37 [Qemu-devel] Hardware watchdogs (patch for discussion only) Richard W.M. Jones
2009-02-26 10:51 ` Daniel P. Berrange [this message]
2009-02-26 13:55   ` Richard W.M. Jones
2009-02-26 19:30     ` Blue Swirl
2009-02-26 14:31   ` Steve Fosdick
2009-02-26 14:45     ` Richard W.M. Jones
2009-02-27  9:55       ` Steve Fosdick
2009-02-26 17:50     ` Jamie Lokier
2009-02-27  9:50       ` Steve Fosdick
2009-02-27 12:19         ` Paul Brook
2009-02-28 21:34           ` Jamie Lokier
2009-02-28 22:00             ` Andreas Färber
2009-02-28 22:11           ` Richard W.M. Jones

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090226105106.GD22494@redhat.com \
    --to=berrange@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).