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 shutdown() function
is called 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 shutdown() call will trigger the reboot kernel
callout defined in the BSP. You need to ensure that this callout contains
measures to place the entire system in a safe state.