QHS components

When implementing a system that will be certified to a safety standard, you should:

obtain the required QNX safety-certified packages
use the safety-certified components delivered in these packages
confirm that you have implemented these components

QNX Software Center packages

Packages for the QHS and supporting safety-certified components are available from the QNX Software Center just like other QNX software packages (see the “Building a Hypervisor System” chapter). The packages of safety-certified components are are identified by the .safety suffix (e.g., target.hypervisor.kernel_module.safety).

Identifying safety components

The safety-certification document issued to you when you purchase the QHS lists the safety-certified components you must use.

When both non-safety and safety variants of a component are available, the files for the safety-certified components made available in these packages include -safety as the last part of the component name before the suffix (e.g., vdev-shmem-safety.so, smmuman-safety, rather than vdev-shmem.so, smmuman).

Confirming component certification

You can use the uname utility's -a option to get information about the hypervisor host's microkernel (procnto-*), and the use utility's -i option to display a load module's build properties (see uname and use in the QNX Neutrino Utilities Reference).

The name, release, and version (timestamp) must all match the information on the corresponding safety-certificates for each component you are using. See the QNX Hypervisor for Safety 2.0 Safety Manual, as well as the Safety Manuals for the other safety components you are using.

Note:

If you build your own safety components, you should identify them in the same manner that the QNX components are identified, get them safety-certified to the appropriate standard, and confirm that the variants you have implemented in your system are indeed the safety-certified variants of these components.

For more information, contact your QNX representative.

QHS component validation

On startup, the QHS default behavior is to check that all the required safety-related components are present and operational. These components include but are not limited to:

architecture-specific virtualization hardware
the qvm process safety variant (qvm-safety)
if DMA devices will be implemented in the system, IOMMU/SMMU units on the board
the smmuman service safety variant (smmuman-safety) to program the IOMMU/SMMU units (see the QNX SMMUMAN User's Guide)
the server-monitor service; there is only one variant, and it is safety-certified, so the name doesn't include the “safety” infix (see “Identifying safety components” above, and server-monitor in the QNX Neutrino Utilities Reference)
the pci_server-qvm_support.so module (required for passing through PCI devices)
the safety variants of vdevs (vdev-*-safety.so)

If any of these components is missing or not running as expected, the QHS default behavior is to move to its DSS (see “Design Safe States” in this chapter).

Behavior according to safety levels, by component

When you configure your VM, you can use the qvm safety option to change this default (see safety in the “VM Component Reference” chapter). The table below lists QHS components and the actions the safety variant of a qvm process instance will take if the safety variant of a required component isn't available on startup, or if it fails:

Component safety status	Behavior of the qvm process instance
Component safety status	safety=required (default)	safety=warn	safety=none
The microkernel (procnto) isn't safety-certified.	Terminate	Issue warning to log output, but continue.	Continue
A vdev that the VM configuration specifies must be safety-certified isn't safety-certified.	Terminate	Issue warning to log output, but continue.	Continue
SMMUMAN components aren't safety-certified (smmuman service is already running).	Terminate	Issue warning to log output, but continue.	Continue
SMMUMAN components aren't safety-certified, but this qvm process instance doesn't use the smmuman service (no pass-through devices are specified in the VM configuration).	Continue	Continue	Continue
The pci-server is running and PCI pass-through devices are specified in the VM configuration, but no pci_server-qvm_support.so library was loaded.	Terminate	Issue warning to log output, but continue.	Continue
No pci-server is running, and no PCI pass-through devices are specified in the VM configuration.	Continue	Continue	Continue

Note:

procnto reports itself as being safety-certified only if it and all kernel modules included (e.g., libmod_qvm) are the safety-certified module variants.
If a VM's safety option is set to warn or none, the qvm safety variant will run even if a non-safety variant of a required component is present (e.g., procnto, pci-server), but the environment will not be a safety environment. If a guest checks if it is running under QHS, the response will be “No” (see “Checking the guest's environment and the hypervisor's safety status” in this chapter).

Guest validation of required components

As required by your safety-certification, you should configure your safety-related guest OSs to move to their DSSs if safety-related components on which they rely aren't present and running correctly. These components may include, but are not limited to:

architecture-specific hardware virtualization support (see your hardware documentation)
the smmuman service for safety running in the guest, which requires the smmuman service for safety running in the hypervisor host