From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1LdWp5-0004T7-Ma
	for qemu-devel@nongnu.org; Sat, 28 Feb 2009 16:34:15 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1LdWp4-0004RT-7I
	for qemu-devel@nongnu.org; Sat, 28 Feb 2009 16:34:15 -0500
Received: from [199.232.76.173] (port=43868 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1LdWp3-0004RE-TC
	for qemu-devel@nongnu.org; Sat, 28 Feb 2009 16:34:13 -0500
Received: from mail2.shareable.org ([80.68.89.115]:42569)
	by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.60) (envelope-from <jamie@shareable.org>) id 1LdWp3-0003Bf-GB
	for qemu-devel@nongnu.org; Sat, 28 Feb 2009 16:34:13 -0500
Date: Sat, 28 Feb 2009 21:34:10 +0000
From: Jamie Lokier <jamie@shareable.org>
Subject: Re: [Qemu-devel] Hardware watchdogs (patch for discussion only)
Message-ID: <20090228213410.GM20640@shareable.org>
References: <20090225233718.GA15750@amd.home.annexia.org>
	<20090226175025.GA10284@shareable.org>
	<1235728224.5894.176.camel@ecrins.fosdick.home.net>
	<200902271219.54657.paul@codesourcery.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200902271219.54657.paul@codesourcery.com>
Reply-To: qemu-devel@nongnu.org
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: qemu-devel@nongnu.org
Cc: Steve Fosdick <lists@pelvoux.nildram.co.uk>

Paul Brook wrote:
> IMHO external watchdog (i.e. ones that monitor qemu itself) are out
> of scope.  We should restrict this to internal watchdog devices
> within a VM.

I agree.  The thing of interest is whether the guest is running, not
whether QEMU is running.

It would be good for the internal watchdog device to have the option
of no effect except for its status to be available in the QEMU
monitor, so management apps can see when the guest has crashed.

Steve's idea of a matrix (Guest event -> QEMU action) is a good one,
and could include "watchdog not pinged" as a guest event.

-- Jamie