QNX Advanced Virtualization Frameworks Architecture

http://qnx.com/developers/docs/7.1/index.html#com.qnx.doc.qavf.overview/topic/overview.html

目录

QNX Advanced Virtualization Frameworks Architecture

Audio Sharing

Host components

Guest components

System-wide audio management

Graphics Sharing

Virtual device

GPU sharing architecture

Graphics virtualization

Display sharing architecture

Shared GPU and Display: Required components

Input Sharing

Filesystem Sharing

---

QNX Advanced Virtualization Frameworks Architecture

QNX高级虚拟化框架是在多个操作系统之间共享图形、音频和输入设备等资源的系统，同时将关键服务和非关键服务的管理分开，以减轻故障的影响。

如下图所示虚拟框架通过前端guest os和后端host os 对共享资源的实现qnx hypervisor 设计，这种设计可以减少guest os 对host os 影响，同时可以在一个ecu 上运行多个系统，从而节省硬件资源。host os 管理关键服务（即仪表盘），host 和 guest os 管理非关键服务（如信息娱乐）。 

此版本侧重于具有多个显示器的驾驶舱域控制器（Cockpit Domain Controllers,CDC），但虚拟化框架也适用于医疗和工业控制等其他市场。

CDC默认设计将仪表盘放置在主机中，并在仪表板显示器上呈现仪表盘。这种设计提供了比将其放置在访客中更高的效率（例如，每帧绘制的CPU使用率更低），信息娱乐应用程序在Android客户机中运行，其他信息娱乐功能在QNX主机中运行，呈现在head unit 上，这样更安全。

此版本所针对的是一个承载一个Android客户机的QNX Hypervisor。QNX Hypervisor也支持其他客户机类型，如Linux和QNX Neutrino。

共享资源框架由虚拟设备（vdev）和/或服务组成，管理程序主机和客户机可以使用它们共享内容。虽然QNX Hypervisor支持通过vdev 实现基本和常见公共操作（如访问共享RAM和共享CPU），但汽车驾驶舱进一步实现的vdev来支持主机和访客之间的共享内容。QNX高级虚拟化框架在以下框架中提供vdev：

• Sensor Sharing
• Shared Audio
• Shared Filesystem
• Shared GPU and Display
• Shared Input
• Shared USB
• Shared Video and Camera
• Virtual Socket

Audio Sharing

共享音频框架允许连接到host 的访客捕获和输出音频。它通过提供一个音频虚拟设备来实现这一点，访客系统可以对该设备进行启动和停止这些操作，配置如采样率等参数。主机控制每个客户机允许哪些操作，以及每个客户机可以访问连接到主机的哪些物理设备。

共享音频框架使运行在虚拟机（VM）中的客户机能够访问在运行的主机中的音频驱动程序和服务，这需要在vm 中配置音频设备。

音频框架提供了一个虚拟设备（vdev）virtio-snd，使访客能够访问主机中的一个或多个音频硬件驱动程序提供的音频功能。此vdev基于VirtIO标准的非官方草案版本1.2。

主机管理访客和物理音频设备之间的所有交互：

• 管理程序主机拥有物理设备，并为这些设备运行驱动程序（deva-*）。
• VM中的客户机需要访问物理设备，VM会向客户机呈现音频vdev（virtio-snd），客户机会运行virtio声音驱动程序与vdev进行交互。此声音驱动程序由操作系统的本地音频服务加载；例如，对于QNX Neutrino客户机，io audio是音频服务。
• 为了相互通信，客户机驱动程序和vdev使用virtqueue，这是VirtIO设备上批量数据传输的标准机制
• 主机上的应用程序可以使用io audio的QNX音频服务来访问音频设备（例如扬声器）

要在QNX Hypervisor系统中支持共享音频，须向来宾和主机image 中添加组件，并在来宾的VM中配置virtio snd vdev。

主主机可以为每个客户机提供不同的音频功能，就像每个客户机在自己的单独板上运行一样。例如，一个客户机可能被允许捕获和输出音频，而另一位客户机只被允许输出音频。

要将主机中的音频功能呈现给任何特定的客户机，需要在承载客户机的VM中配置virtio snd vdev。vdev配置指定主机上哪些PCM流暴露给客户机，还指定了必须应用于访客的音频参数的任何限制，例如采样率、支持的格式以及最小和最大片段大小。

Host components

To enable the audio framework, you must have the following components on your host:

• the audio drivers (deva-*) that you would use for audio when running the QNX Neutrino RTOS on your target board
• the host audio service (io-audio) to provide the guests and host applications access to audio capture, playback, and management features
• an audio device configuration file (e.g., io-audio.conf) that configures the audio devices for the host
• an audio management configuration file (e.g., audio_policy.conf) that configures the audio policy for the host (optional)
• the vdev that provides access to audio functionality, virtio-snd. The vdev module, vdev-virtio-snd.so, must be included in the shared object list of your hypervisor host buildfile.
• for each VM that hosts a guest that needs to use audio, the virtio-snd vdev is configured; for information on how to do this, see “vdev virtio-snd”
• the path to the configuration file (*.qvmconf) for each guest that's running in a VM is included in your hypervisor host buildfile

Guest components

Because the virtio-snd vdev is a para-virtualized device, a guest must have a VirtIO sound driver that can communicate with the vdev.

虚拟机中vdev 配置

vdev virtio-snd
  [loc addr intr intr]
  [stream type
    [nid node_id]
    [rates audio_rates]
    [formats audio_formats]
    [channels numbers_of_channels | chmap map *]
    [pcmpath host_path]
    [audio_type type] ]*
  [control name
    [nid node_id]
    [ctlpath mixer_control_path]
    [switchname mixer_switch_name]
    [switchdev mixer_switch_device]
    [groupname mixer_group_name]
    [groupindex mixer_group_index]
    [groupcaps mixer_capabilities] ]*

System-wide audio management

Graphics Sharing

图形共享由共享GPU和显示框架支持。该框架支持主机和客户机之间共享图形内容，并包括虚拟设备、虚拟渲染库和其他服务。

GPU功能

• GPU共享允许客户虚拟机（VM）和主机同时使用主机上的图形处理单元（GPU）。应用程序使用GPU在图像缓冲区中生成像素内容；GPU不在显示器上显示内容。

display

• 显示共享使访客的图像缓冲区能够显示在连接到主机的显示器上。

To use this framework, your host system must have the Screen Graphics Subsystem. This component is included in your QNX SDP installation and can be included in a hypervisor host image and started on the target after booting. For links to examples, see the “Integration Support for Android” chapter.

Virtual device

The Shared GPU and Display framework uses a virtual device (vdev) that implements section 5.7 (“GPU Device”) of the VirtIO 1.1 specification, which is available from oasis-open.org. This vdev, virtio-gpu, manages guest access to the host's GPU and display controller.

This chapter explains the framework's architecture, how to configure the virtio-gpu device in a VM to make it available to a guest, and how to add the necessary components to the guest and host

GPU sharing architecture

共享GPU和显示框架能让运行在虚拟机（VM）中的客户机访问主机系统上的GPU资源。

客户应用程序进行图形渲染必须使用客户操作系统支持的渲染库和窗口系统。例如，对于QNX Neutrino客户机，渲染库可以是OpenGL，窗口系统必须是Screen。

主机管理访客和GPU之间的交互。访客必须知道自己正在虚拟化环境中运行，其渲染库和窗口系统必须使用适当的驱动程序与virtio gpu vdev通信。
客户机或主机应用程序进行渲染图形时，它们使用本地图形中间件（即渲染库和窗口系统）的方法没有变化——GPU共享对这些应用程序是透明的。来自客户应用程序的图形命令通过中间件传递给客户驱动程序，客户驱动程序将它们转发给vdev。来宾驱动程序和vdev间使用virtqueue相互通信，vdev使用配置的虚拟渲染库生成图像内容；来自主机应用程序的图形命令通过图形中间件传递到物理GPU的驱动程序。

下图说明了客户组件、virtio-gpu-vdev、主机组件和gpu硬件之间的交互。

Graphics virtualization

当来宾应用程序在其渲染库（即图形命令）中执行API调用时，这些调用将转发到主机上执行实际渲染的库。此功能称为图形虚拟化，由以下组件支持：

virtio-gpu vdev

virtio-gpu-vdev是一种准虚拟化设备，它允许在主机上执行来自客户机的图形命令。此vdev在虚拟机监控程序VM（ a hypervisor VM）中运行，但不模拟GPU。在此vdev的配置中，可以指定要使用哪个虚拟渲染库来执行这些命令。

Virtual rendering libraries

该框架包括以下库，用于处理图形API调用并在主机上进行三维渲染：

• 图形流工具包（GFXStream）库libgfxstream.so，支持Vulkan和OpenGL。
• VirGL库libvirglrenderer.so仅支持OpenGL。

在vdev配置中选择的库通过vdev接收图形命令，并与GPU驱动程序交互以生成3D图像内容。然后，可以在连接到主机的物理显示器上显示此内容。

对于Android访客，必须使用其中一个库，因为Android无法在2D模式下运行。对于可以在2D模式下操作的访客，可以不用这些库。还需要在客户机中使用正确的中间件组件，并将其配置为使用这些主机端渲染库。

以下示例显示了由主机管理的Android客户机、QNX客户机和GPU之间的交互：

Display sharing architecture

共享GPU和显示框架使在虚拟机（VM）中运行的访客能够在连接到主机系统的显示器上显示内容。该框架仅支持在从访客到主机的方向上共享虚拟显示。访客可以将与应用程序关联的多个窗口发送到主机上的物理显示器。可能也有专用于客户机的特定显示器和/或管道。通过使用此框架，访客可以将绘图工作转移到帧缓冲区或合成最终场景以供主机显示。

当客户机操作完全由硬件加速时，渲染和显示的图形任务在主机上执行，合成内容仅在主机上。如果访客机需要执行CPU合成，则必须将内容上传（传输）给访客。传输操作具有CPU成本；要传输的内容更少意味着图形虚拟化的性能更好。
在主机上，虚拟显示输出可以作为本机屏幕窗口访问。用户可以通过使用Screen API对窗口执行他们想要的操作。默认情况下，virtio-gpu将在默认主机显示器上显示内容；这可以在vdev的选项中配置。

来自主机应用程序的GPU命令通过图形中间件到达GPU驱动程序。当主机应用程序从该驱动程序接收到生成的图像缓冲区时，它们会将它们发送到Screen，Screen与显示控制器交互，将图像内容渲染到物理显示器上。在所有渲染管道上进行最终的场景合成，这需要显示包含访客和宿主内容的各种窗口。

下图说明了所有客户组件、virtio-gpu-vdev、主机组件以及gpu和显示控制器硬件之间的交互。

以下示例显示了从Android和Linux客户机到主机，然后到显示硬件中的管道的典型内容流：

在这个例子中，Android客户机配置了一个虚拟显示器，其内容将在主机上的显示器1上显示。Linux客户机配置了两个虚拟显示器，这两个显示器的内容也将显示在显示器1上。客户应用程序通过其自己的图形中间件（未显示）生成和渲染图像内容，并使用适当的驱动程序将内容发送到其虚拟显示器。此内容可以与主机screen window 模块交互。

Shared GPU and Display: Required components

Host components

To enable GPU and display sharing on the host, you must ensure that:

• The following files are included in the shared object list of your hypervisor host buildfile:
  • vdev-virtio-gpu.so
  • libvirglrenderer.so
  • libgfxstream.so
• For each VM that hosts a guest that uses graphics sharing, the virtio-gpu vdev is configured. For information on how to enable GPU sharing and configure your virtual displays, see the vdev virtio-gpu reference.
• The path to the configuration file (*.qvmconf) for each guest that's running in a VM is included in your hypervisor host buildfile.
• The host image contains the Screen Graphics Subsystem. This component is included in QNX SDP and therefore is present in the default buildfile in any hypervisor host BSP.
• A graphics configuration file (e.g., graphics.conf) that contains your Screen configuration for the host is included in the host buildfile

Guest components

Because the virtio-gpu vdev is a para-virtualized device, the guest must have a VirtIO driver that can communicate with this vdev.

QNX Neutrino guests

For QNX Neutrino guests, you must use:

• the drm-virtio driver.

  This driver is provided with the QNX Software Development Platform (SDP). See the drm-virtio entry in the Screen Graphics Subsystem Developer's Guide.

• a graphics configuration file (e.g., graphics.conf) that contains your drm-virtio configuration and your Screen display configuration

Android and Linux guests

For Android and Linux guests, you must use the virtio-gpu.ko kernel driver. You also need the right middleware components and to configure them appropriately to use the host-side rendering libraries of libvirglrenderer.so and libgfxstream.so. On the guest, the client (middleware) libraries might have different names.

vdev virtio-gpu
    [loc addr intr intr]
    gfxstream | virgl
    [render_options options]
    [vdisp [virtual_display1 options [: [virtual_display2 options]...]]]

Input Sharing

vdev virtio-input [display display_id]
                  [force_dev_presence enabled]
                  [global_alpha number]
                  [loc addr intr guest_intr]
                  [offset x_offset,y_offset]
                  [options [+|-]bitmask]
                  [pipeline number]
                  [protocol b]
                  [sched priority]
                  [size x_dimension,y_dimension]
                  [window window_id]
                  [zorder zorder]
                  screen input_type

Filesystem Sharing

vdev virtio-fs [directio enabled]
               [host_path dir]
               [loc addr intr guest_intr]
               [num_req_queues num]
               [sched priority]
               [tag name]

vdev virtio-fs
  loc 0x1c0fe000
  intr gic:56
  tag qhostfs    # Tag to use in the guest's mount command.
  num_req_queues 1
  host_path /mnt/qnx_host # If you set this to a resource manager path (e.g., /pps),
                 # set directio to "true" below.
  directio false # Set to "true" to pass -D to the FUSE deamon.

mkdir /mnt/qnx_host
mount -t virtiofs qhostfs /mnt/qnx_host