QNX Technical Articles
QNX® Hypervisor 2.0: Release Notes
Date of this edition: Monday, October 22, 2018
Target platforms
The QNX Hypervisor 2.0 release supports AArch64 and x86-64 hardware platforms. It has been tested on the platforms for which reference images are provided; that is, for ARM:
- Renesas R-Car H3
and for x86:
- Intel Broadwell NUC
- Intel Gordon Ridge MRB
 |
The default ABL included with the Intel Gordon Ridge MRB doesn't support virtualization. We have conducted our QNX Hypervisor 2.0 testing for Gordon Ridge MRB boards with ABL 1729. Please contact Intel to obtain an ABL that supports virtualization, and install it on your board. The default bootloader included with the Renesas R-Car H3 boards doesn't boot into EL2, which is required for the QNX Hypervisor. This is common for many ARM boards. For more information about how to get and build an appropriate bootloader, please see “Renesas R-Car H3” in the QNX Hypervisor 2.0 User's Guide. |
Qualcomm support
In addition to the platforms listed above, QNX Hypervisor 2.0 fully supports the Qualcomm Snapdragon 820A processor family. The concepts and architecture described in the QNX Hypervisor 2.0 User's Guide apply to these Qualcomm platforms (e.g., virtual machine configuration, virtual device setup).
The board support software needed to run the QNX Hypervisor 2.0 on the Qualcomm hardware is currently provided by the Qualcomm software team. Please contact your QNX Sales team to coordinate the involvement of the Qualcomm software team.
Host OSs
You can work with the QNX Hypervisor from any host system that supports the QNX Software Development Platform 7.0:
- Linux Red Hat Enterprise Linux 7 64-bit, or Ubuntu Desktop 16.04 LTS 64-bit
- Microsoft Windows 10 Professional 64-bit, Windows 8.1 Professional 64-bit, or Windows 7 Professional 64-bit
- macOS version 10.10, 10.11, 10.12
Build environments
You will also need the appropriate environments to modify and build the guest OSs you plan to run in the hypervisor's virtual machines (VMs):
- QNX SDP 7.0 for the hypervisor host domain and QNX Neutrino OS 7.0 guests
- QNX SDP 6.6.0 for QNX Neutrino 6.6.0 guests
- appropriate build environments for Linux, Android or other guest OSs
For more information, see the “Assembling a Hypervisor System and Its Components” chapter in the QNX Hypervisor 2.0 User's Guide.
Contents
- What's in this release?
- Installation
- Known issues
- Fixed issues
- Technical support
- Where can I get more information?
What's in this release?
This release supports and has been tested with the following guest OSs:
- QNX Neutrino RTOS 6.6.0 (x86 only)
- QNX Neutrino RTOS 7.0
- Linux OS 16.04
This QNX Hypervisor 2.0 General Availability (GA) release is the first production-quality release in our QNX Hypervisor 2.0 program. If you have been working with our Early Access release, you will already be familiar with most of the contents and functionality of the QNX Hypervisor 2.0.
As well as being a GA release, this release differs from Early Access releases in several ways (references above are to chapters and sections in the QNX Hypervisor 2.0 User's Guide):
- Packaging and delivery – like other QNX products, the QNX Hypervisor 2.0 GA product, the reference images, and the related BSPS are available from the QNX Software Center (see “Getting Started”).
- Build process – the methods available for building the hypervisor host and assembling a hypervisor system including guests has been streamlined (see “Assembling a Hypervisor System and Its Components”).
- DMA device containment – a system memory management unit (IOMMU/SMMU) manager (smmuman) utility is now shipped with the hypervisor; smmuman must be running on the hypervisor host to support pass-through hardware devices that use DMA (see “DMA device containment (smmuman)”).
- Networking – the preferred networking strategy is now to use devnp-vdevpeer.so, an io-pkt-* driver that provides the hypervisor host with a network interface to connect to a guest's virtio-net vdev (see “Networking” and “devnp-vdevpeer.so”).
- Watchdogs – this release provides virtual watchdog devices, as well as the wdtkick watchdog kicker for QNX Neutrino OS guests. These components aren't hypervisor components; they are included in the hypervisor package for users' convenience (see “Watchdogs” and “wdtkick”).
- Linux guests – the reference images don't include Linux guests. See the QNX Hypervisor 2.0 User's Guide, and Technical Support on the QNX Hypervisor Public Forum for details about how to easily build and run Linux guests.
QOS 2.0 compatibility – a hypervisor kernel module compatible with QOS 2.0 is now available. If you are using QOS 2.0, you must use this module (libmod_qvm-qos_capable.a) instead of the libmod_qvm.a module. Be sure to modify your hypervisor host build file accordingly (i.e., in the procnto build line of your image buildfile for the host, use module=qvm-qos_capable instead of module=qvm; see “QNX SDP 7.0 or QOS 2.0?”).
The current hypervisor release is not a safety-related product. The libmod_qvm-qos_capable.a module is provided for development purposes only. It is made available as a convenience to allow you to develop a safety-related hypervisor system, but adding it to a QOS 2.0 build compromises the QOS 2.0 safety certification.
Installation
Installation of the QNX Hypervisor 2.0 is now done from the QNX Software Center. The QNX Software Center has all the components you will need for your hypervisor system, including reference images, the hypervisor host kernel and virtualization module, and BSPs for supported hardware platforms as well as for guests running in hypervisor virtual machines (VMs).
The QOS 2.0-compatible virtualization module is available from the Software Center as well.
The QNX Hypervisor 2.0 User's Guide has detailed installation instructions. For instruction on how to:
- get and install the hypervisor system reference images, see “Getting Started”
- get and build (or re-build) the hypervisor, its VMs, and its guests, see “Assembling a Hypervisor System and Its Components”
|
If you've already installed the QNX Hypervisor and you want to install com.qnx.sdp.target.microkernel.core: Kernel and libc 7.0 BuildID 991 - September 18, 2018, install com.qnx.sdp.target.hypervisor.group: QNX Hypervisor (with Debug Symbols) 2.0 BuildID 900 - October 4, 2018 2.0.900.S201810041259 before you install the rest of the update. |
The QNX Hypervisor 2.0 development environment
QNX recommends that you create a new development environment for your QNX Hypervisor 2.0, even if you already have a QNX SDP 7.0 environment set up on your development host.
The QNX Hypervisor 2.0 is built on QNX SDP 7.0. Hypervisor files are uniquely named, so installing the QNX Hypervisor 2.0 packages won't overwrite existing files in your QNX SDP 7.0 target or host environments.
However, in some cases a board support file, or a QNX SDP 7.0 target or host file may require updating in order to work properly in a hypervisor system. The change may be one you make yourself, or one recommended to you by QNX Engineering.
It is best to prepare for such possible changes when you first install QNX Hypervisor 2.0 to your development host. To do this, in the QNX Software Center, choose + Add Installation (top left) to download the QNX Hypervisor 2.0 packages to a new build environment.
Reference images
All the components you will need to install and run a QNX Hypervisor 2.0 system on a supported platform are included in the reference images available from the QNX Software Center. Reference images are available for the following hardware platforms:
ARM
- Renesas R-Car H3
x86
- Intel Gordon Ridge MRB
- Intel Broadwell NUC
BSPs
If you will modify and build hypervisor systems, you may need to get additional BSPs. Remember the following:
- Your hypervisor host needs the board-specific BSP for the hardware platform on which it will run.
- QNX guests need guest OS release-specific and architecture-specific hypervisor guest BSPS; for example: “QNX SDP 7.0 Hypervisor guest (QNX SDP 6.6) for generic ARM virtual machines”.
- Even if you already have a BSP for your board, get the latest BSP (see note below).
Some earlier hardware BSP's posted on the QNX Software Center may have problems when configured to run as a hypervisor host. Always use the latest BSP available to you from the Software Center, unless QNX engineering explicitly recommends otherwise.
Patches
Your QNX Hypervisor 2.0 system may rely on functionality in guests that was provided in patches issued since you obtained your QNX Neutrino OS release. For example, QNX Neutrino OS 6.6 requires a patch for correct PCI functionality.
Always update your system (including your guests) with the latest patches, unless QNX engineering explicitly recommends otherwise.
Startup
The QNX Hypervisor 2.0 User's Guide “Getting Started” chapter has instructions on how to:
- get a QNX Hypervisor 2.0 reference image
- transfer a reference image to your board and boot the hypervisor
- start a qvm process and boot a guest
Rebuilding a system
When you are ready to build your own system, just follow the instructions in the User's Guide “Assembling a Hypervisor System and Its Components” chapter.
|
Remember that when you are setting up your QNX SDP 7.0 environment, you should download and install any QNX SDP 7.0 patches that are available from the Software Center. Similarly, if you are building a QNX Neutrino OS 6.6 guest, download and install any QNX SDP 6.6 patches that are available from the Software Center. |
Known issues
This release contains known issues in the following areas:
- On ARM platforms, PCI isn't supported for QNX Neutrino OS 6.6 guests. (Ref. 2533221)
On Intel Gordon Ridge MRB boards, a serial device configured as a pass-through device to a QNX Neutrino OS 6.6. guest may not behave as expected. For example, the devc-serpci driver will start in the guest but may exit without detecting any devices. (Ref. 2530627)
Workaround: Update the devc-serpci driver to the latest driver supplied by QNX for the Intel Gordon Ridge MRB board.
On Renesas R-Car boards, assigning to a QNX Neutrino OS guest more virtual CPUs (vCPUs) than there are physical CPUs on the hardware may cause the guest and host consoles to become unresponsive. (Ref. 2236058)
Workaround: QNX recommends that you don't configure more vCPUs for a guest than there are physical CPUs on a board. However, if your design requires this configuration on a Renesas R-Car board, then do the following: use the cpu sched option to give vCPU 0 for the guest a higher priority than the other vCPUs defined for that guest.
For more information about vCPU limits, see “Configuring VM components” in the User's Guide “Configuration” chapter.
The hypervisor's use of the MSI capability means that a guest driver may find that the MSI vectors are initially masked. We have observed that some drivers (e.g., QNX Neutrino OS 6.6 Ethernet) do not unmask the MSI vectors as expected, and are thus not able to receive interrupts from the device. (Ref. 2250729).
Workaround: In the guest experiencing problems, clear the masking bits in the MSI capability before starting the driver. For example, for the Ethernet device on a QNX Neutrino 6.6 guest, use the pci-tool utility tool as follows:
pci-tool -dB:D:F --write CFG:0x60=0
where B is the bus, D is the device, and F is the function, as seen by the guest.
Note that the offset used above is device-specific; it may change for other devices.
The User's Guide doesn't specify that on ARM platforms, to use a PCI device with MSI-X capabilities, you must specify the msi option. (Ref. 2533956)
For example: vdev gic msi 0x30000000,0x200,0x100
After installing the PCI update required for the QNX Hypervisor 2.0, Software Center verification may issue the following warning:
Package: QNX(R) SDP 7.0 OS services - OS services base Severity: HIGH Type: ChangedFileSize Files: target/qnx7/aarch64le/usr/sbin/rsrcdb_query target/qnx7/armle-v7/usr/sbin/rsrcdb_query target/qnx7/x86/usr/sbin/rsrcdb_query target/qnx7/x86_64/usr/sbin/rsrcdb_query target/qnx7/aarch64le/usr/sbin/rsrcdb_query.sym target/qnx7/armle-v7/usr/sbin/rsrcdb_query.sym target/qnx7/x86/usr/sbin/rsrcdb_query.sym target/qnx7/x86_64/usr/sbin/rsrcdb_query.sym
This issue is caused by the rsrcdb_query binary moving to the PCI package. The warning may be safely ignored; the issue will be corrected in a subsequent update to the OS Services Base Package. (Ref. 2534523)
Technical support
To obtain more technical information about your QNX product, visit the QNX Hypervisor Public Forum website (http://community.qnx.com/sf/sfmain/do/viewProject/projects.qnx_hypervisor_public_forum), or contact your QNX FAE.
|
The QNX Hypervisor Public Forum pages are not private. They are open to all Hypervisor 2.0 users. For private conversations, please contact your QNX FAE or QNX CSP project manager directly. |
Where can I get more information?
The QNX Hypervisor 2.0 User's Guide has information about QNX virtual environments; QNX hypervisor architecture and design; configuring the hypervisor, VMs, and guests; virtual paravirtualized, and passthrough devices; instructions for installing and building the hypervisor and its guests; information about how to set up networks, and shared memory; and information for debugging and troubleshooting your hypervisor system and its component parts.