From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id C7ACAC433F5 for ; Sat, 23 Apr 2022 09:37:12 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234439AbiDWJkH (ORCPT ); Sat, 23 Apr 2022 05:40:07 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52168 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230527AbiDWJkD (ORCPT ); Sat, 23 Apr 2022 05:40:03 -0400 Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B91576EC4B; Sat, 23 Apr 2022 02:37:06 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sin.source.kernel.org (Postfix) with ESMTPS id 2510ACE1413; Sat, 23 Apr 2022 09:37:05 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 58CC4C385A5; Sat, 23 Apr 2022 09:37:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1650706623; bh=Bc6OdO5zLa9E4y5fJUFO7NvkfYqgJXyZP6qe3WITbq0=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=I+KSaIShLnEU0k9sdPDlltMqlZGecjFhx+hvFXPMC3GtG++1FhdwgtjR4kFs78K2v fStWd+RUN+8+jyahwk7XdX335iPAReuAJ/5W1hK7NqpnXaeeHKE5Gml/zKNcqNxC1l 846TmDn4PKpru9+nbjvIjzWADO4f/Ea2D9rPdVHI0n52VLbVzARt6A5MIDic7Jl9Sk 6h2Sjqb+OdHUWYLzw3eL92ymNWOZOLrBa1Yj4WO3Gw/BB50tQYkTI84eCvVSeZd1As ZKi1rLpuZtiXTnXYqnchYJfLm7tggFJw3IqxirtC41DPj5JtWuUFBCak23TI76CJ9K pt/gY73i4d//w== Received: from sofa.misterjones.org ([185.219.108.64] helo=billy-the-mountain.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1niCCK-006MIm-RO; Sat, 23 Apr 2022 10:37:00 +0100 Date: Sat, 23 Apr 2022 10:36:56 +0100 Message-ID: <877d7gcf9j.wl-maz@kernel.org> From: Marc Zyngier To: Sebastian Ene Cc: Greg Kroah-Hartman , linux-kernel@vger.kernel.org, Derek Kiernan , Dragan Cvetic , Arnd Bergmann , Rob Herring , devicetree@vger.kernel.org, qperret@google.com, will@kernel.org Subject: Re: [PATCH v2 0/2] Detect stalls on guest vCPUS In-Reply-To: References: <20220422141949.3456505-1-sebastianene@google.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: sebastianene@google.com, gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org, derek.kiernan@xilinx.com, dragan.cvetic@xilinx.com, arnd@arndb.de, robh+dt@kernel.org, devicetree@vger.kernel.org, qperret@google.com, will@kernel.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On Sat, 23 Apr 2022 10:02:24 +0100, Sebastian Ene 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.