QNX hypervisors provides virtual watchdog devices that you can use in a VM just as you would a hardware watchdog on a board in a non-hypervisor system.
It is your responsibility to determine how best to use hardware and software watchdogs for the hypervisor host as well as for guests. This is of particular importance in safety-related systems.
Refer to your QNX Hypervisor for Safety 2.0 and QNX OS for Safety 2.1 Safety Manuals for the safety requirements and recommendations concerning watchdogs. If you need advice about how to implement watchdogs, please contact your QNX representative.
A QNX hypervisor is a QOS or QNX Neutrino OS microkernel plus virtualization support. As such, it provides the same support for a watchdog as the microkernel of which it is a superset. If a hardware watchdog exists, you can use a board-specific utility to kick it, and use the High Availability Manager (HAM) or the System Launch and Monitor service (SLM) to manage the host in the event that a watchdog detects an anomaly in the host's behavior (see ham and slm in the QNX Neutrino OS Utilities Reference).
To learn more about watchdogs in QNX systems, see the OS Core Components documentation; to learn more about your board-specific watchdog kicker utility, see your board's BSP User's Guide.
The watchdog vdevs implemented with QNX hypervisors emulate a hardware watchdog in a VM. A watchdog kicker utility (see wdtkick in the QNX SDP Utilities Reference) running in the guest enables its virtual hardware watchdog, then writes at specific intervals to guest-physical registers monitored by the watchdog vdev to inform the watchdog that the guest is running (it “kicks” the watchdog).
If the watchdog kicker fails to write to the registers within the required delay, the watchdog vdev can trigger an appropriate action, such as forcing the qvm process instance to exit.
Since the qvm process is a QNX OS process, you can trap its exit codes just as you do for any OS process (see the QNX Neutrino OS documentation). If you are implementing a watchdog service for your guests, you should configure your hypervisor host to trap the qvm process exit codes so you can decide what you want the host to do in the event that a qvm process instance terminates unexpectedly (see “qvm exit codes” in the “Monitoring and Troubleshooting” chapter). These actions can range from simply logging the error and waiting for user intervention, to using the High Availability Manager to attempt to restart the qvm process and its guest OS.
For information about how to cause the guest to dump in response to a watchdog bite, see “Getting a guest dump” in the “Monitoring and Troubleshooting” chapter.
To implement a watchdog service in a QNX guest running in a QNX hypervisor VM, you need to:
Implement a watchdog kicker in the guest, and configure it to kick the watchdog vdev (for QNX guests the kicker is provided in the BSP, see “QNX guest watchdog kicker (wdtkick)” below).
For Linux and Android guests, see “Implementing a watchdog in a Linux or Android guest” below.
The watchdog vdevs emulate a subset of the functions provided by hardware watchdogs. Refer to the chip documentation for information about your hardware watchdog (e.g., the SP805 documentation at the ARM Documentation Center).
QNX hypervisor BSPs include scripts for starting and stopping watchdogs in your QNX guests. These are located in the BSP's scripts directory:
To start or stop your watchdog vdev and the kicker in the QNX guest, run either watchdog-start.sh or watchdog-stop.sh, as appropriate.
The wdtkick watchdog kicker is board-specific for QNX guests in a QNX hypervisor system (see wdtkick in the QNX SDP Utilities Reference). It is shipped in the BSPs for supported boards. For hypervisor systems, it is included in the BSPs for QNX guests at hardware/support/wdtkick.
The buildfiles for the QNX guests made available with the hypervisor include commented out sections with configurations for wdtkick. To use these utilities, you can uncomment these files and rebuild your guest.
For reference, below are examples of wdtkick configurations for ARM and for x86 guests.
Kick the watchdog every second (1), and set the timeout period to three (3) seconds, which in fact translates to six (6) seconds because the timer on ARM platforms counts down twice and asserts the reset only on the second timer expiry:
wdtkick -v -a 0x1C0F0000 -t 1000 -E 8:3 -W 0:0x47868C0
where:
Kick the watchdog every five (5) seconds, and set the timeout period to 10 seconds:
wdtkick -v -a 0x441 -t 5000 -w 8 -W 2:0xA
where:
You can enter the watchdog kicker configuration via the command line at startup, or you can modify your guest startup to store it in the guest system page's hwinfo section (see the “System Page” chapter in Building Embedded Systems).
For up-to-date information about your board-specific watchdog kicker utility, see the wdtkick.use file included with the BSP.
For information about the watchdog vdevs, see vdev wdt-sp805 (ARM) and vdev wdt-ib700 (x86) in the “Virtual Device Reference” chapter.
If you want to use a watchdog in a Linux or Android guest, you must do the following:
Enable the watchdog module – the Linux or Android kernel must include the correct watchdog kernel module for your target (IB700 or SP805).
In most Linux and Android distributions, this module isn't enabled by default. See menuconfig, and the Linux kernal configuration documentation's “Device Drivers” section for details on how to rebuild a Linux kernel with the watchdog module enabled.