devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: Sebastian Ene <sebastianene@google.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	linux-kernel@vger.kernel.org,
	Derek Kiernan <derek.kiernan@xilinx.com>,
	Dragan Cvetic <dragan.cvetic@xilinx.com>,
	Arnd Bergmann <arnd@arndb.de>, Rob Herring <robh+dt@kernel.org>,
	devicetree@vger.kernel.org, qperret@google.com, will@kernel.org
Subject: Re: [PATCH  v2 0/2] Detect stalls on guest vCPUS
Date: Sat, 23 Apr 2022 10:36:56 +0100	[thread overview]
Message-ID: <877d7gcf9j.wl-maz@kernel.org> (raw)
In-Reply-To: <YmPAoFjfGoBHbPjC@google.com>

On Sat, 23 Apr 2022 10:02:24 +0100,
Sebastian Ene <sebastianene@google.com> wrote:
> 
> On Sat, Apr 23, 2022 at 08:51:16AM +0200, Greg Kroah-Hartman wrote:
> > On Fri, Apr 22, 2022 at 02:19:48PM +0000, Sebastian Ene wrote:
> > > This adds a mechanism to detect stalls on the guest vCPUS by creating a
> > > per CPU hrtimer which periodically 'pets' the host backend driver.
> > > 
> > > This device driver acts as a soft lockup detector by relying on the host
> > > backend driver to measure the elapesed time between subsequent 'pet' events.
> > > If the elapsed time doesn't match an expected value, the backend driver
> > > decides that the guest vCPU is locked and resets the guest. The host
> > > backend driver takes into account the time that the guest is not
> > > running. The communication with the backend driver is done through MMIO
> > > and the register layout of the virtual watchdog is described as part of
> > > the backend driver changes.
> > > 
> > > The host backend driver is implemented as part of:
> > > https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3548817
> > > 
> > > Changelog v2:
> > >  - move the driver to misc as this does not cope with watchdog core
> > >    subsystem
> 
> Hello Greg,
> 
> > 
> > Wait, why does it not cope with it?  That's not documented anywhere in
> > your patch that adds the driver.  In fact, most of the text here needs
> > to be in the changelog for the driver submission, not thrown away in the
> > 00/XX email that will never end up in the kernel tree.
> > 
> > thanks,
> > 
> > greg k-h
> 
> From the previous feedback that I received on this patch it seems that
> watchdog core is not intended to be used for this type of driver. This
> watchdog device tracks the elapsed time on a per-cpu basis,
> since KVM schedules vCPUs independently. Watchdog core is not intended
> to detect CPU stalls and the drivers don't have a notion of CPU.

I must say that I don't really get the objection against the watchdog
approach. OK, there is no userspace aspect to this.  But we already
use watchdogs for more than just userspace (reboot is one of the major
use cases).

There already are per-CPU watchdog in the tree: see how the
fsl-ls208xa platform has one SP805 per CPU (8 of them in total). As
far as I can tell, there was no objection to this. So what is special
about this one?

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.

  reply	other threads:[~2022-04-23  9:37 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-22 14:19 [PATCH v2 0/2] Detect stalls on guest vCPUS Sebastian Ene
2022-04-22 14:19 ` [PATCH v2 1/2] dt-bindings: vm-wdt: Add qemu,vm-watchdog compatible Sebastian Ene
2022-04-22 21:10   ` Rob Herring
2022-04-22 14:19 ` [PATCH v2 2/2] misc: Add a mechanism to detect stalls on guest vCPUs Sebastian Ene
2022-04-23  6:50   ` Greg Kroah-Hartman
2022-04-23  9:14     ` Sebastian Ene
2022-04-23  9:22       ` Greg Kroah-Hartman
2022-04-23  6:51 ` [PATCH v2 0/2] Detect stalls on guest vCPUS Greg Kroah-Hartman
2022-04-23  9:02   ` Sebastian Ene
2022-04-23  9:36     ` Marc Zyngier [this message]
2022-04-23 11:12       ` 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=877d7gcf9j.wl-maz@kernel.org \
    --to=maz@kernel.org \
    --cc=arnd@arndb.de \
    --cc=derek.kiernan@xilinx.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dragan.cvetic@xilinx.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=qperret@google.com \
    --cc=robh+dt@kernel.org \
    --cc=sebastianene@google.com \
    --cc=will@kernel.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).