From: Sebastian Ene <sebastianene@google.com>
To: Rob Herring <robh+dt@kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Arnd Bergmann <arnd@arndb.de>,
Dragan Cvetic <dragan.cvetic@xilinx.com>
Cc: linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
maz@kernel.org, will@kernel.org, vdonnefort@google.com,
Guenter Roeck <linux@roeck-us.net>,
Sebastian Ene <sebastianene@google.com>
Subject: [PATCH v12 0/2] Detect stalls on guest vCPUS
Date: Mon, 11 Jul 2022 08:17:18 +0000 [thread overview]
Message-ID: <20220711081720.2870509-1-sebastianene@google.com> (raw)
Minor change from v11 which cleans up the Kconfig option selection.
This adds a mechanism to detect stalls on the guest vCPUS by creating a
per CPU hrtimer which periodically 'pets' the host backend driver.
On a conventional watchdog-core driver, the userspace is responsible for
delivering the 'pet' events by writing to the particular /dev/watchdogN node.
In this case we require a strong thread affinity to be able to
account for lost time on a per vCPU basis.
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 v12:
- don't select LOCKUP_DETECTOR from Kconfig when VCPU_STALL_DETECTOR is
compiled in as suggested by Greg
- add the review-by tag received from Guenter
Changelog v11:
- verify the values from DT if they are in an expected range and
fallback to default values in case they are not.
- added Will's review-by tag
Changelog v10:
- keep only the hrtimer and a flag in the per_cpu structure and move
the other fields in a separate config structure
- fix a potential race condition as pointed out by Will: the
driver remove(..) can race with the hotplug cpu notifiers
- replace alloc_percpu with devm_alloc_percpu and remove the free_percpu
- unregister the hotplug notifiers
- improve the Kconfig description and fix the license in the header
file
- add the review-by tag from Rob as the DT has not changed since v9
Changelog v9:
- make the driver depend on CONFIG_OF
- remove the platform_(set|get)_drvdata calls and keep a per-cpu static
variable `vm_stall_detect` as suggested by Guenter on the (v8) series
- improve commit description and fix styling
Sebastian Ene (2):
dt-bindings: vcpu_stall_detector: Add qemu,vcpu-stall-detector
compatible
misc: Add a mechanism to detect stalls on guest vCPUs
.../misc/qemu,vcpu-stall-detector.yaml | 51 ++++
drivers/misc/Kconfig | 13 +
drivers/misc/Makefile | 1 +
drivers/misc/vcpu_stall_detector.c | 223 ++++++++++++++++++
4 files changed, 288 insertions(+)
create mode 100644 Documentation/devicetree/bindings/misc/qemu,vcpu-stall-detector.yaml
create mode 100644 drivers/misc/vcpu_stall_detector.c
--
2.37.0.rc0.161.g10f37bed90-goog
next reply other threads:[~2022-07-11 8:17 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-11 8:17 Sebastian Ene [this message]
2022-07-11 8:17 ` [PATCH v12 1/2] dt-bindings: vcpu_stall_detector: Add qemu,vcpu-stall-detector compatible Sebastian Ene
2022-07-11 8:17 ` [PATCH v12 2/2] misc: Add a mechanism to detect stalls on guest vCPUs Sebastian Ene
2022-07-14 14:54 ` [PATCH v12 0/2] Detect stalls on guest vCPUS Greg Kroah-Hartman
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=20220711081720.2870509-1-sebastianene@google.com \
--to=sebastianene@google.com \
--cc=arnd@arndb.de \
--cc=devicetree@vger.kernel.org \
--cc=dragan.cvetic@xilinx.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=maz@kernel.org \
--cc=robh+dt@kernel.org \
--cc=vdonnefort@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
all inboxes | Powered by JetHome®