From: Guenter Roeck <linux@roeck-us.net>
To: Sebastian Ene <sebastianene@google.com>
Cc: Wim Van Sebroeck <wim@linux-watchdog.org>,
Rob Herring <robh+dt@kernel.org>,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-watchdog@vger.kernel.org, will@kernel.org,
qperret@google.com, maz@kernel.org
Subject: Re: [PATCH 2/2] watchdog: Add a mechanism to detect stalls on guest vCPUs
Date: Tue, 5 Apr 2022 14:15:51 -0700 [thread overview]
Message-ID: <20220405211551.GB2121947@roeck-us.net> (raw)
In-Reply-To: <20220405141954.1489782-3-sebastianene@google.com>
Sebastian,
On Tue, Apr 05, 2022 at 02:19:55PM +0000, Sebastian Ene wrote:
> This patch adds support for a virtual watchdog which relies on the
> per-cpu hrtimers to pet at regular intervals.
>
The watchdog subsystem is not intended to detect soft and hard lockups.
It is intended to detect userspace issues. A watchdog driver requires
a userspace compinent which needs to ping the watchdog on a regular basis
to prevent timeouts (and watchdog drivers are supposed to use the
watchdog kernel API).
What you have here is a CPU stall detection mechanism, similar to the
existing soft/hard lockup detection mechanism. This code does not
belong into the watchdog subsystem; it is similar to the existing
hard/softlockup detection code (kernel/watchdog.c) and should reside
at the same location.
Having said that, I could imagine a watchdog driver to be used in VMs,
but that would be similar to existing watchdog drivers. The easiest way
to get there would probably be to just instantiate one of the watchdog
devices already supported by qemu.
Guenter
next prev parent reply other threads:[~2022-04-06 2:32 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-05 14:19 [PATCH 0/2] Detect stalls on guest vCPUS Sebastian Ene
2022-04-05 14:19 ` [PATCH 1/2] dt-bindings: watchdog: Add qemu,vm-watchdog compatible Sebastian Ene
2022-04-06 12:25 ` Rob Herring
2022-04-06 16:34 ` Sebastian Ene
2022-04-05 14:19 ` [PATCH 2/2] watchdog: Add a mechanism to detect stalls on guest vCPUs Sebastian Ene
2022-04-05 21:15 ` Guenter Roeck [this message]
2022-04-06 16:31 ` Sebastian Ene
2022-04-06 16:52 ` Guenter Roeck
2022-04-08 14:03 ` Sebastian Ene
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=20220405211551.GB2121947@roeck-us.net \
--to=linux@roeck-us.net \
--cc=devicetree@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-watchdog@vger.kernel.org \
--cc=maz@kernel.org \
--cc=qperret@google.com \
--cc=robh+dt@kernel.org \
--cc=sebastianene@google.com \
--cc=will@kernel.org \
--cc=wim@linux-watchdog.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).