safety

Updated: October 28, 2024

Specify how a qvm process instance responds if any component or vdev it uses isn't safety-certified

Synopsis:

safety none|warn|required

Options:

One of the following:
none
Look for the safety-certified version of each component and, if found, load it; otherwise, load the non-safety version and don't issue a warning.
warn
Look for the safety-certified version of each component and, if found, load it; otherwise, load the non-safety version but issue a warning.
required
Look for the safety-certified version of each component and, if not found, issue an error message and move the hypervisor to the global Design Safe State (DSS).
The default behaviors for different QNX hypervisors are as follows:
  • QNX Hypervisor for Safety (QHS) — required
  • QNX Hypervisor — none

Description:

Use the safety option to specify how each qvm process instance responds to the presence of uncertified (i.e., non-safety) components or vdevs.

For a qvm process to consider a vdev to be a safety variant, the vdev must have these characteristics:
  • the filename has the -safety suffix (e.g., vdev-virtio-blk-safety.so instead of vdev-virtio-blk.so)
  • the vdev has the VDEV_SAFETY bit set at compile time. If you're building your own safety-certified vdevs, contact the QNX support team for details on how to proceed.

    If you don't set this bit and instead try to rename a vdev to include the -safety suffix, qvm doesn't consider this to be a safety variant.

  • the vdev went through safety certification
Note: In QHS systems, the qvm process instance checks for the safety variant of the microkernel, procnto-safety. If QNX SMMUMAN software is used on the target and the VM configuration defines at least one DMA-capable pass-through device, qvm similarly checks for the presence of the SMMUMAN safety variant, smmuman-safety.

If you specify multiple safety option instances in a VM configuration, the final option instance determines how qvm responds to the presence of uncertified components (e.g., an uncertified procnto or smmuman variant).

Each safety option instance applies to the vdevs that follow it in the configuration. For example, consider the following configuration settings:
safety warn
vdev foo
safety required
vdev moo
In a QHS VM for a QOS guest, this configuration issues a warning and permits the qvm process instance to continue if the foo vdev isn't a safety variant, but moves to the DSS if the moo vdev isn't a safety variant. The qvm process also moves to the DSS if any other required safety component such as procnto or smmuman isn't a safety variant.
In contrast, consider the following configuration settings:
vdev foo
safety warn
vdev moo
In this case, because required is the default safety setting for QHS, the qvm process instance moves to the DSS if the foo vdev isn't a safety variant. But because warn is the setting for the last safety option, the qvm process instance issues a warning but still runs if the moo vdev or any other required safety component isn't a safety variant.

For more information about how the QHS behaves when it encounters uncertified components, see QHS components in the QNX Hypervisor for Safety: Protection Features chapter.