Home
QNX Advanced Virtualization Frameworks User's Guide
This User's Guide is aimed at all systems integrators and developers who want to design and build embedded systems using the QNX Advanced Virtualization Frameworks.
Virtual Socket
The Virtual Socket framework provides a simple mechanism for passing data between the host and a guest, or between guests, independently of network protocols.
vdev virtio-vsock
Provide socket functionality to guests running in hypervisor VMs

QNX Momentics IDE User's Guide
This User's Guide describes version 7.1 of the Integrated Development Environment (IDE) that's part of the QNX Momentics tool suite.
QNX Software Development Platform
QNX SDP is a cross-compiling and debugging environment, including an IDE and command-line tools, for building binary images and programs for target boards running QNX Neutrino 7.1.
QNX Hypervisor
The QNX Hypervisor allows you to run multiple OSs on a target system so you can separate critical and non-critical functions, support a wide variety of applications, and reduce hardware costs.
QNX Software in the Cloud
QNX Software in the Cloud enables developers to use the QNX software in Amazon Web Services (AWS) and Microsoft Azure (Azure).
QNX Advanced Virtualization Frameworks User's Guide
This User's Guide is aimed at all systems integrators and developers who want to design and build embedded systems using the QNX Advanced Virtualization Frameworks.
- QNX Advanced Virtualization Frameworks Architecture
  The QNX Advanced Virtualization Frameworks allow you to build systems that share resources such as graphics, audio, and input devices among multiple OSs, while separating the management of critical services and non-critical services to mitigate the effects of faults.
- Audio Sharing
  The Shared Audio framework allows guests to capture and output audio on devices connected to the hypervisor host. It does this by providing an audio virtual device through which guests can start and stop these operations and configure parameters such as sampling rate.
- Camera Sharing
  The Shared Video and Camera framework allows the host and guests to share the same camera.
- Filesystem Sharing
  The Shared Filesystem framework allows guests to access directories on the host through mountpoints of their choosing. The framework does this by providing a virtual filesystem device through which guests can interact with files in shared host directories as though they were local files.
- Graphics Sharing
  Graphics sharing is supported by the Shared GPU and Display framework. This framework supports sharing graphical content between the host and guests, and includes a virtual device, virtual rendering libraries, and other services.
- Input Sharing
  The Shared Input framework allows guests and the hypervisor host to share access to input devices. Specifically, it provides a virtual device that lets guests access input from physical devices connected to the hypervisor host.
- Sensor Sharing
  The Sensor Sharing framework allows guests to read data from sensors connected to the hypervisor host. Sensor support will vary. Presently, the framework allows guests to access Inertial Measurement Unit (IMU) sensors on the hypervisor host.
- USB Sharing
  The Shared USB framework allows guest and host applications to share access to USB devices. Specifically, it provides a virtual device that lets guests access USB devices connected to the hypervisor host.
- Virtual Socket
  The Virtual Socket framework provides a simple mechanism for passing data between the host and a guest, or between guests, independently of network protocols.
  - Framework architecture
    The Virtual Socket framework allows the hypervisor host and guests to exchange data using standard socket API calls.
  - Required components
    There are virtual socket components for both the guest and host layers. To allow a guest to use the virtual socket, you must add its vdev to the guest's VM configuration. After it's added to a guest or host OS image, the vdev requires no configuration to send or receive data, except if you have to launch its driver manually for recovery purposes.
  - vdev virtio-vsock
    Provide socket functionality to guests running in hypervisor VMs
  - Running the io-vsock driver
    The io-vsock driver is launched at startup in the QNX Hypervisor host and QNX Neutrino guests. You should start io-vsock manually only if the process terminates unexpectedly. Before trying to do so, always confirm that the service isn't already running by checking the list of active processes with pidin or ps.
  - Adapting TCP/IP socket code to use virtual sockets
- VPU Sharing
  The Shared Video and Camera framework allows guests to use the video processing unit (VPU) on the host system to decode video. The framework does so by providing a virtual video device that provides media codec and video control functionality to client guest applications and uses the host system's VPU to do the required codec operations.
- Integration Support for Android
  The QNX Advanced Virtualization Frameworks support integrating Android into a QNX Hypervisor system with minimal changes to the Android Operating System. This is possible by supporting common Android OS versions and services, adhering to industry standards for virtualization, and allowing existing components to be reused unmodified. There's also a demonstration system that shows how applications in an Android guest can use the virtualization frameworks.
Typographical Conventions, Support, and Licensing
This section describes the typographical conventions used throughout the documentation and explains how to obtain technical support.

vdev virtio-vsock

Provide socket functionality to guests running in hypervisor VMs

Synopsis

vdev virtio-vsock guest_cid [loc addr intr gic:vector]

Options

guest_cid: Computer ID (CID) for the guest using the virtual socket device. This mandatory option must be an unsigned integer between 3 and 0xffffffff–1. (Values 0, 1, and 2 are reserved, with 2 always being used for the hypervisor host.)
Note:
Applications that want to communicate over the virtual socket with this guest must specify this CID in any socket calls.
intr gic:vector: Interrupt vector used for the device in the guest's emulated Generic Interrupt Controller (GIC).
loc: Starting address of the device representation in the guest's virtual address space.

Description

(ARM and x86) To use virtual sockets in a guest, the vdev-virtio-vsock device must be added to the VM in which the guest runs. This is done through a command in the qvm configuration file for this VM. The mandatory guest_cid option uniquely identifies the guest in the hypervisor system. Some target platforms require additional options.

Examples

The command to add the device consists of a vdev virtio-vsock statement on one line, followed by the driver options on their own lines:

# For an AArch64 target, we need to specify the location and interrupt.
# To learn about these properties, see the QNX Hypervisor documentation.
vdev virtio-vsock
        guest_cid 3
        loc 0x1c0f6000
        intr gic:46

# For an x86_64 target, we don't need to specify the location and interrupt.
vdev virtio-vsock
        guest_cid 3

For details on defining qvm configuration files, including their structure, contents, and syntax, see the Assembling and configuring VMs section in the QNX Hypervisor User's Guide.

Page updated: March 12, 2026