The QNX Hypervisor for Safety supports two Design Safe States (DSSs).
CAUTION:
Without adherence to the safety manual, there is no guarantee
that the hypervisor will enter into one of its DSSs following an undefined condition in
a VM or the hypervisor itself.
If an internal or external detection mechanism alerts the hypervisor of a condition it is
not designed to handle in any other way, the hypervisor should do one of the following:
- VM DSS (local DSS)
-
If an undefined condition is confined to a VM,
the hypervisor terminates that qvm process instance
(e.g., with a SIGSEGV signal). Terminating the hosting
qvm process instance terminates its guest.
The hypervisor continues to run normally after it terminates a qvm
process instance. You can design your system to take appropriate action after moving
a guest to its local DSS; for example, you can reconstruct the VM and reboot the guest.
- Hypervisor host DSS (global DSS)
-
Since the QNX Hypervisor for Safety comprises the QNX OS for Safety
microkernel plus a virtualization extension,
the same conditions that cause the QNX OS to move to its DSS cause the hypervisor host to move to its DSS.
That is, if the undefined condition isn't confined to a VM, the hypervisor shuts down. This DSS is the same
as the QNX OS for Safety DSS.
Warning:
- The hypervisor host kernel initiates a shutdown sequence on the CPU where the undefined condition is found.
If a crash occurs in an ISR (Interrupt Service Routine), then there is no kernel lock and the other CPUs may
continue to run.
- The last thing the kernel's shutdown sequence does is to trigger the kernel reboot callout, which must be
provided in the BSP. This callout must ensure that it places the entire system in a safe state.
Typically, this means rebooting the system, which will reset all processors and peripherals.