QNX-9—QNX官网文档翻译—Understanding QNX Virtual Environments

注：翻译自
QNX Hypervisor --> QNX Hypervisor 2.2 User's --> Understanding QNX Virtual Environments
https://www.qnx.com/developers/docs/7.1/index.html#com.qnx.doc.hypervisor.user/topic/virt/virt.html

一、概述

QNX 虚拟机管理程序旨在满足 Popek/Goldberg（波佩克/戈德堡） 定理指定的虚拟机管理程序的期望。

在尝试使用虚拟机管理程序之前，请阅读本章并了解其内容。 现在花几分钟阅读本章将为您将来节省大量时间。

波佩克/戈德堡定理
Popek/Goldberg 定理指定虚拟机管理程序应满足以下三个标准：

(1) 等价
在虚拟机管理程序中运行的虚拟机 (VM) 本质上与底层硬件相同。 来宾不需要知道它正在虚拟机中运行即可正常运行。
上述声明并不排除使用半虚拟化设备（参见本章半虚拟化设备“Para-virtualized devices”）或其他需要虚拟化意识的策略。 此类策略可用于提供功能并提高性能。

(2) 安全
除了来宾访问直通设备内存之外，虚拟机管理程序始终保持对硬件的控制，无论来宾在做什么。 它控制来宾对硬件设备的访问能力，限制来宾访问主机物理内存的内能力到其分配的内存区域，对调度有最终控制，管理中断路由，并且能够终止来宾，无论来宾正在尝试做什么。

(3) 性能
在虚拟机中运行的程序的执行速度仅比直接在硬件上运行时慢一点。

请参阅 Edouard Bugnion、Jason Nieh 和 Dan Tsafrir 所著《Hardware and Software Support for Virtualization》（Morgan & Claypool，2017 年）中的“Popek/Goldberg 定理”。

二、A note about nomenclature

关于命名的注释，在开始使用 QNX Hypervisor (QH) 或 QNX Hypervisor for Safety (QHS)（“虚拟机管理程序”）之前，了解我们用来描述 QNX 虚拟环境、虚拟机管理程序及其来宾的术语会很有用，及我们用于文件名的命名法。

2.1 术语

请注意以下有关本指南中使用的术语的信息：

(1) device

我们使用设备来表示作为系统上的物理组件存在的硬件设备。 对比vdev。

(2) guest

来宾是来宾操作系统以及在此操作系统上运行的任何应用程序； qvm 流程实例（见下文）托管来宾。 来宾在 qvm 中运行。
如果我们需要区分来宾操作系统和应用程序，我们会详细说明（例如，“在不停止来宾操作系统的情况下停止应用程序......”）。

(3) host

在大多数情况下，术语“host”不是指主机（台式机或笔记本电脑，您可以将其连接到目标系统以加载新映像或调试），而是指虚拟机管理程序或虚拟机管理程序中的某些内容（例如，“CPU 指示来宾线程退出来宾模式并继续以主机模式”）。
当上下文无法明确主机的含义时，我们将使用开发主机来指代台式机或笔记本电脑，并使用主机域或虚拟机管理程序主机来表示虚拟机管理程序及其所有组件。
在讨论权限或异常级别时，我们将使用虚拟机管理程序主机或虚拟机管理程序主机域（例如，“在虚拟机管理程序主机域中运行的进程有时在 ARM 板上的 EL2 下运行，或在 x86 板上的 VMX 根模式下运行”）。

(4) hypervisor

为简单起见，我们可以使用术语 QNX 虚拟机管理程序或虚拟机管理程序来指代 QH 和 QHS 变体。 如果您使用的是 QHS，请参阅 QNX Hypervisor for Safety 2.2 安全手册。

(5) qvm

qvm（或 qvm 进程）是虚拟机管理程序中托管来宾的进程。
hypervisor启动qvm进程实例； 每个 qvm 流程实例都提供一个虚拟机 (VM)，来宾可以在其中运行。
qvm 进程有时以虚拟机监控程序主机域（它是虚拟机监控程序的一部分）的权限级别运行，有时以它所托管的来宾的较低权限级别运行。

(6) vdev

我们使用虚拟设备（或 vdev）来表示虚拟机管理程序以某种方式虚拟化的任何设备（请参阅本章中的“Virtual devices”）。 vdev 的示例包括中断控制器（虚拟化）或以太网设备控制器（半虚拟化）。
如果我们将虚拟设备简单地称为设备，那会令人困惑并且是错误的，所以请让我们知道这一点。

(7) VM

虚拟机（或 VM）由 qvm 进程实例呈现给在 VM 中运行的来宾； VM 托管来宾。

有关更完整的术语表，请参阅术语附录。

2.2 Filenames

我们使用以下术语来命名 QNX 虚拟化环境中的文件：

(1) Prefixes

前缀标识文件的使用位置：

hypervisor

该文件包括或用于构建和/或配置管理程序主机域。 前缀后跟版本号。

vdev-

该文件是一个虚拟设备。

(2) Suffixes

后缀标识文件类型：

.build

该文件是用于 QNX 虚拟机管理程序主机域或 QNX 来宾的构建文件。
对于 Linux 和其他非 QNX 客户机，请参阅这些类型操作系统的文档。

.img

该文件是可启动映像。 该映像可以仅包括管理程序主机域、仅包括一个来宾，或者包括主机域和一个或多个来宾。

.qvmconf

该文件是VM的配置文件； 它由 qvm 进程实例解析以组装 VM。

(3) 例子

下面说明了我们如何组成文件名：

Hypervisor build and image files

虚拟机管理程序主机域的构建文件和映像文件的名称组成如下：hypervisorrelease-board.type，其中 release 是虚拟机管理程序版本，board 是硬件平台，type 是文件类型（build 或img）。 例如：hypervisor2.2-fooboard.build 和 hypervisor2.2-fooboard.img。

Guest (QNX) build and image files

来宾构建文件和映像的名称组成如下：guestos.type，其中 guestos 是来宾操作系统（例如 qnx71、linux44），type 是文件类型（build 或 img）。 如果您的 QNX 虚拟机管理程序系统将具有同一操作系统的多个实例，请为每个实例添加一个字母； 例如：qnx71a.build 和 qnx71b.img。
Linux 和其他类型的来宾操作系统使用自己的术语。

VM configuration files

qvm 进程的配置文件名称组成如下： guest.qvmconf，其中 guest 是将在该文件配置的 VM 中运行的来宾操作系统（例如 qnx71、linux44）。 如果您的 QNX 虚拟机管理程序系统将具有同一操作系统的多个实例，请为每个实例添加一个字母； 例如：qnx71a.qvmconf 和 qnx71b.qvmconf。

三、Supported architectures, hardware, and guest OSs

3.1 支持的硬件架构

此版本的虚拟机管理程序支持以下硬件架构：

ARM
ARMv8 硬件上的 AArch64

x86
x86 硬件上的 x86-64

3.2 CPU特权级别

CPU 特权级别控制当前在处理器上运行的程序对内存区域、I/O 端口和特殊指令等资源的访问。 来宾以比虚拟机管理程序微内核更低的权限运行，并且在该来宾中运行的应用程序以更低的权限运行。 该架构提供了来自不受信任的软件组件的硬件级安全性。

另请参见“Terminology”附录中的“Exception Level (EL)”和“Ring”。

3.3 PCI支持

QNX 软件系统 PCI 供应商 ID 为 7173 (0x1C05)。 有关 PCI 供应商 ID 的更多信息，请参阅 PCI SIG 网站：https://pcisig.com/。 有关 QNX PCI 供应商 ID 的更多信息，请联系您的 QNX representative。

3.4 支持的来宾操作系统

此虚拟机管理程序版本支持上述指定硬件架构的 QNX 操作系统、Linux 和 Android 客户机。 支持的来宾包括：

(1) QNX Neutrino 7.1
(2) Linux Ubuntu 18.04 or 16.04
(3) Android Nougat, or more recent

来宾操作系统必须针对运行虚拟机管理程序主机的硬件架构进行编译。 例如，AArch64 guest 虚拟机只能在 ARMv8 硬件上运行。 有关支持的来宾操作系统的信息，请参阅 QNX Hypervisor Release Notes。

64 位和 32 位来宾

对于 ARM 和 x86 平台，虚拟机管理程序主机域需要 64 位硬件并支持 64 位来宾。 来宾可以作为单核或多核运行； 也就是说，来宾可以在配置有单个虚拟 CPU (vCPU) 的 VM 中运行，也可以在配置有多个 vCPU 的 VM 中运行。

尽管虚拟机管理程序包含启用它们的代码，但严格的 32 位来宾操作系统并未得到正式支持。如果您需要 32 位客户操作系统的支持，请联系您的 "QNX support team"  以获取选项。 选项可以包括有关使用虚拟机管理程序验证此来宾操作系统或在 64 位来宾操作系统上运行 32 位应用程序的指导。

QNX Hypervisor 支持可运行 32 位应用程序的 64 位客户操作系统环境，例如 Android 或 Linux。

虚拟机中 vCPU 的数量会影响性能。 添加 vCPU 将 vCPU 线程添加到托管来宾虚拟机的 qvm 进程实例。 尽管与硬件 CPU 核心的数量无关，但系统设计人员选择的 vCPU 数量通常与物理核心的数量相关。 “性能调整”一章对此进行了进一步解释。

增加虚拟机中的 vCPU 数量可以提高性能，但请参阅本章中的 “Architecture” 和 “Virtual machines” 以及 “Performance Tuning” 章节，以了解额外 vCPU 可能会降低性能的情况。

四、Architecture

QNX 虚拟机管理程序由虚拟机管理程序微内核、虚拟化扩展以及一个或多个 qvm 进程实例组成。

4.1 QNX 虚拟机管理程序系统的两种表示形式

下图展示了 QNX 虚拟机管理程序架构的上层视图以及可用于访问虚拟和物理设备的一些配置。 并未显示所有可能的访客设备配置； 所示的这些仅用于说明一些可能的配置。

图 1. 虚拟机管理程序概述，显示虚拟机以及来宾访问虚拟和物理设备的一些方式。

上图展示了虚拟机管理程序系统的静态视图。 不幸的是，它必然具有误导性，因为它可以被解释为建议来宾实际上在虚拟机或主机系统上运行； 更糟糕的是，在描述虚拟机管理程序系统时，我们经常说来宾在虚拟机中运行。

事实上，来宾实际上并不在虚拟机中运行。 虚拟机管理程序不是为 CPU 翻译客户指令的中介。 VM 定义虚拟硬件（请参阅本章“Virtual devices”），并将其和直通硬件（请参阅本章“Pass-through devices”）呈现给来宾，来宾不需要知道它是在 VM“中”运行，而不是在由硬件直接定义的环境中。

也就是说，当来宾运行时，其指令在物理 CPU 上执行，就像来宾在没有虚拟机管理程序的情况下运行一样。 仅当来宾尝试执行不允许执行的指令或访问管理程序正在监视的来宾内存时，虚拟化硬件才会捕获该尝试并强制来宾退出。

在陷阱trap上，硬件通知管理程序，管理程序保存来宾的上下文（来宾退出）并完成来宾已开始但无法自行完成的任务。 任务完成后，虚拟机管理程序恢复来宾的上下文并将执行权交还给来宾（来宾入口）。

下面的 Lahav 线展示了虚拟机管理程序与其来宾之一之间交互的更动态视图。 为简单起见，它假定执行路径位于单个 CPU 上。

图 2. Lahav 线显示 QNX 虚拟机管理程序系统中的执行如何在虚拟机管理程序及其来宾之间交替。 在陷阱上，虚拟机管理程序管理来宾出口，保存来宾的上下文，然后在来宾入口之前将其恢复。

有关虚拟机管理程序如何减轻来宾中的时间漂移（由于需要让来宾退出而导致）的信息，请参阅本章中的“Time”。

五、Virtual machines

正在运行的虚拟机管理程序包括虚拟机管理程序微内核及其虚拟化模块，以及虚拟机进程（qvm）的一个或多个实例。

5.1 什么是虚拟机？

在 QNX 虚拟机管理程序环境中，VM 在 qvm 流程实例中实现。 qvm 进程是在虚拟机管理程序主机中运行的操作系统进程，位于内核之外。 每个实例都有一个标识符来标记它，以便微内核知道它是一个 qvm 进程。

如果您还记得有关虚拟机的任何信息，请记住，从来宾操作系统的角度来看，托管该来宾的虚拟机是硬件。 这意味着，正如在物理主板上运行的操作系统需要某些硬件特征（架构、主板特性、内存和 CPU、设备等）一样，在虚拟机中运行的操作系统也需要这些特征： 运行必须符合来宾的期望。

关于事物出现位置的规则与真实板子相同：

(1) 不要安装两个尝试响应同一物理地址的东西。
(2) 您的虚拟机配置组装的环境必须是您将运行的软件（来宾操作系统）准备处理的环境。

硬件类比也适用于另一个方向。 虚拟机不需要知道其来宾正在做什么，就像硬件不需要知道操作系统正在做什么一样。 事实上，VM 无法知道来宾正在做什么（“来宾是一个 blob”；请参阅“术语”附录）。

例如，虚拟机无法知道来宾退出的原因（即，来宾是否因为用户请求关闭或遇到致命错误而退出）。 如果您需要知道客人退出的原因，您需要依靠客人告诉您原因。 如果来宾还没有这样做的机制，您需要添加适当的机制。 对于 QNX 访客，“关机”屏幕可能会提供所需的功能，具体取决于您的要求。

有关配置 VM 的更多信息，请参阅“Assembling and configuring VMs”一章中的“Configuration”。

5.2 qvm services

每个 qvm 流程实例都提供关键的虚拟机管理程序服务。

1. 虚拟机组装和配置

为了创建来宾操作系统可以运行的虚拟环境，qvm 进程实例在启动时会执行以下操作：

(1) 读取、解析和验证虚拟机配置文件 (*.qvmconf) 以及启动时使用进程命令行输入的配置信息，如果配置无效则退出，并向日志打印一条有意义的错误消息。

(2) 设置中间阶段表（ARM：第 2 阶段页表，x86：扩展页表 (EPT)）。

(3) 创建（组装）并配置其VM，包括：

a. 为来宾分配 RAM（读/写）和 ROM（仅 r）

b. 为其提供给来宾的每个虚拟 CPU (vCPU) 提供一个线程 

c. 提供传递设备以供客人使用

d. 为托管来宾定义和配置虚拟设备 (vdev)

2. 虚拟机操作

在 VM 操作期间，qvm 进程实例执行以下操作：

(1) 捕获出站和入站访客访问尝试并确定如何处理它们（即，如果地址指向 vdev，则调用 vdev 代码（访客退出，然后在 vdev 代码完成时访客进入）；如果地址确实超出界限，就这样对待它）。

(2) 在放弃物理 CPU 之前保存其来宾的上下文。

(3) 在将来宾重新执行之前恢复其来宾的上下文。

(4) 负责任何故障处理。

(5) 执行确保虚拟机完整性所需的任何维护活动。

3. 访客启动和关闭

VM 中的来宾可以像在硬件上一样启动。 从客户机的角度来看，它开始在物理 CPU 上执行。 然而，这个CPU实际上是一个qvm vCPU线程。 来宾可以启用其中断，就像在非虚拟化系统中运行一样。

当来宾虚拟机中的第一个 vCPU 线程开始执行时，虚拟机可以知道该来宾已启动。

发起访客关闭是访客的责任。qvm 进程检测通过常用方法（例如 PSCI 或 ACPI）启动的关闭。 如果您想使用 qvm 无法自动识别的方法，您可以编写一个 vdev 来检测关闭操作并做出适当的响应。

有关编写 vdev 的更多信息，请参阅“Virtual Device Developer's Guide”。

如果虚拟机管理程序检测到虚拟机中未定义的情况，虚拟机管理程序将终止该虚拟机的 qvm 进程实例，从而终止来宾（请参阅 QNX Hypervisor: Protection Features” 一章中的 “Design Safe States”）。

5.3 管理访客上下文

在虚拟化环境中，CPU 虚拟化扩展负责根据来宾的操作识别来宾何时需要退出。 然而，当 CPU 触发来宾退出时，托管来宾的 qvm 进程实例（即 VM）会保存来宾的上下文。 qvm 流程实例完成来宾发起的操作，然后在允许来宾重新进入之前恢复来宾的上下文（请参阅“Performance Tuning”一章中的“Guest exits”）。

5.4 管理权限级别

qvm 流程实例管理来宾入口和出口处的权限级别，以确保来宾可以运行，并保护系统免受错误代码的影响。

在来宾入口处，qvm 进程实例要求 CPU 为来宾提供运行所需的权限级别，但仅此而已。 在访客退出时，qvm 进程实例会要求 CPU 返回在虚拟机管理程序主机中运行所需的权限级别。

只有 CPU 硬件可以更改特权级别。 qvm 进程执行使 CPU 更改特权级别所需的操作。 这种机制（因此是操作）是特定于体系结构的。

5.5 访客访问虚拟和物理资源

每个 qvm 流程实例管理其托管来宾对虚拟和物理资源的访问。

当来宾尝试访问其来宾物理内存中的地址时，此访问可以是以下其中之一，并且托管来宾的 qvm 进程会检查访问尝试并按所述进行响应：

(1) 允许

来宾正在尝试访问它拥有的内存区域。
qvm 流程实例不执行任何操作。

(2) 直通设备

来宾正在尝试访问分配给物理设备的内存，并且来宾的VM配置为知道来宾可以直接访问该设备。
qvm 流程实例不执行任何操作。 访客直接与设备通信。

(3) 虚拟设备

访客正在尝试访问分配给虚拟设备（虚拟或半虚拟）的地址。
qvm 流程实例请求适当的权限级别更改，并将执行传递给所请求设备的代码。 例如，来宾 CPUID 请求会触发 qvm 流程实例来模拟硬件并对来宾做出响应，就像硬件在非虚拟化系统中的响应一样。

(4) 过错

来宾正在尝试访问其无权访问的内存。
qvm 流程实例向来宾返回适当的错误。

以上是针对通过 CPU 的访问尝试。 DMA 访问控制由 SMMU 管理器管理（请参阅“DMA device containment (smmuman)”）。

六、Memory

在 QNX 虚拟化环境中，客户视为连续物理内存的客户物理内存实际上可能是由虚拟化组装的不连续主机物理内存。

QNX 虚拟化环境中的来宾使用内存用于：

(1) 正常操作（请参阅本章“虚拟化环境中的内存”）
(2) 访问直通设备（请参阅本章“直通内存”）
(3) 与其他客人共享信息（请参阅本章“共享内存”）

请注意以下有关 QNX 虚拟机管理程序中内存的信息：

(1) 除共享内存外，分配给 VM 的内存仅供该 VM 托管的来宾使用； 也就是说，每个来宾的地址空间是排他的并且独立于管理程序系统中任何其他来宾的地址空间。
(2) 如果系统上没有足够的可用内存来完成为 VM 配置的内存分配，虚拟机管理程序将无法完成配置，也不会启动 VM。
(3) 如果分配给其托管 VM 的内存不足以供 guest 虚拟机使用，则无论板上有多少可用内存，guest 虚拟机都无法启动。
(4) 除了用于直通设备以防止信息泄漏的内存之外，虚拟机管理程序在将内存分配给虚拟机之前将其清零。 根据分配给客户机的内存量，这可能需要几秒钟的时间。

6.1 虚拟化环境中的内存

在 QNX 虚拟化环境中，配置有 1 GB RAM 的来宾将看到 1 GB 可用内存，就像它在非虚拟化环境中运行时看到可用 RAM 一样。 此内存分配对于来宾来说显示为物理内存。 它实际上是由虚拟化配置从不连续的物理内存组装而成的内存。 ARM将这种组装好的内存称为中间物理内存； 英特尔称之为客户物理内存。 为简单起见，无论平台如何，我们都将使用客户物理内存（请参阅术语中的“Guest memory”）。

当您在 QNX 虚拟化环境中配置和访问内存时，请务必记住以下几点：

(1) 分配给来宾和任何其他用途的内存总量不得超过主板上可用的物理内存。
(2) 内存分配必须是 QNX OS 系统页面大小 (4 KB) 的倍数。
(3) 访客看到的内存是由不连续的内存块组装而成的。 该客户物理内存对客户来说就像物理内存在非虚拟化系统中一样； 例如，在 x86 系统上，它对于传统设备等会有相同的差距。
(4) 来宾看到的表面上的物理地址实际上是来宾物理内存中的来宾物理地址，该地址由 qvm 进程在创建 VM 时组装。
(5) 来宾看到的地址（来宾物理地址）与来宾物理地址最终在虚拟化层下转换为的物理地址（主机物理地址）之间不存在对应关系。

图 1. 说明客户操作系统将内存视为连续物理内存，并通过虚拟化配置从不相关的物理内存区域进行组装。

上图简化说明了 QNX 虚拟化系统中如何从不连续的物理内存块组装来宾内存分配。 为了简化该图，Guest 1 的内存分配不完整，并且为了易读性，在 guest 虚拟机之间添加了间隙。 另请注意，物理内存的某些区域可能会被保留（例如，对于板架构在特定位置需要的设备）并且不能分配给来宾。

为来宾配置内存时，您需要配置内存分配的大小以及任何特定于平台的信息，例如旧设备 (x86) 的间隙或 RAM 起始地址 (ARM)。 虚拟机管理程序负责将物理内存块组装成每个客户的客户物理内存分配。

6.2 直通内存

作为直通设备访问物理设备的来宾需要将这些设备映射到配置为可供它们访问的内存区域。 请注意，直通设备的客户物理地址不一定与管理程序域中的主机物理地址相同。 换句话说，来宾看到的物理地址和从管理程序主机域看到的物理地址之间不存在对应关系。

图 2. 说明访客将直通设备视为物理地址的访客物理地址如何与设备的主机物理地址不对应。

例如，设备 A 可能配置在 Guest 0 的物理内存中的 0x100 处。 该设备可以在同一位置 (0x100) 配置为 Guest 0 的直通设备，因此当 Guest 0 需要访问该设备时，它会查看 0x100。 然而，我们应该记住，当客户机查看物理地址时，它正在查看客户机物理地址，该地址会转换为主机物理内存中的其他地址，例如 0xC00000100。

有关直通设备的详细信息，请参阅本章中的“Pass-through devices”。

6.2 共享内存

部分物理内存可以分配给来宾之间共享。 来宾将使用 vdev-shmem 等虚拟设备连接到相同的物理地址 (PA)，并使用共享内存区域来共享数据，每当新数据可用或已读取时就会相互触发。

物理地址 (PA) 是主机中的实际物理地址，而不是客户机物理地址。 不同访客的访客物理地址很可能会有所不同。

图 3. 两个来宾之间共享内存的图示。 每个客人都将这段内存视为自己的内存。

有关如何在虚拟机管理程序系统中实现内存共享的信息，请参阅 “Using a QNX Hypervisor System” 一章中的 “Memory sharing”。

6.3 配置内存

要为虚拟机（VM）分配内存，必须分配系统各个部分所需的内存。 您不会在一个块中为虚拟机分配所有内存。 相反，您分配镜像所需的内存，然后分配各种设备所需的内存，等等。

许多系统都有保留的内存区域。 对于 x86 系统尤其如此，它需要在特定位置使用许多残留设备。 这些规则适用于在虚拟环境中运行的来宾，因为操作系统期望残留设备存在。

当您分配内存时，仅指定可启动映像在来宾物理内存中的位置，并让 qvm 进程选择设备、共享内存等的位置可能会更有效。

如果 RAM 位置用于来宾的可引导映像，则必须将来宾配置为在其内存内的该地址处查找映像。 此外，如果您使用 qvm 配置加载组件来加载可启动映像，则加载映像的地址必须与 guest 虚拟机的配置相匹配。 （如果您不指定地址，qvm 进程会为您处理该地址。）

例如，对于 QNX 来宾，您可以执行以下操作：

为客户映像分配 RAM，客户物理内存中的起始地址为 0x80000000：

ram 0x80000000,128M

将可启动映像加载到此位置：

load 0x80000000,/vm/images/qnx7.ifs

在来宾的构建文件中指定此位置：

[image=0x80000000]
[virtual=aarch64le,elf] .bootstrap = {
   [+keeplinked] startup-armv8_fm -v -H
   [+keeplinked] PATH=/proc/boot procnto -v
}

请参阅 “VM Configuration Reference” 一章中的 “ram”。

6.4 DMA 设备限制 (smmuman)

虚拟机管理程序使用 IOMMU/SMMU 管理器 (smmuman)，确保没有直通设备能够访问尚未明确授予其访问权限的主机物理内存。

QNX Hypervisor for Safety 需要 SMMUMAN for Safety (smmuman-safety) 服务才能运行。 此外，如果您作为来宾运行 QNX OS for Safety，则该来宾还必须运行 SMMUMAN for Safety。
有关 smmuman 和 smmuman-safety 服务以及如何使用它们的更多信息，请参阅“QNX Hypervisor: Protection Features” 中的 “DMA device containment (smmuman)” 以及《SMMUMAN User's Guide》。

七、Devices

QNX 虚拟机管理程序为访客提供对物理设备（包括直通和共享设备）以及虚拟设备（包括仿真和半虚拟化设备）的访问。

关于设备访问

配置 QNX 虚拟化环境（虚拟机管理程序、虚拟机的 qvm 进程和来宾）时，您需要将物理设备和虚拟设备 (vdev) 分配给虚拟机管理程序和来宾。 要正确执行此操作，您不仅需要知道设备是物理设备还是虚拟设备，还需要知道物理设备还是虚拟设备的类型，因为这决定了：

(1) 如果来宾或虚拟机管理程序必须包含设备驱动程序
(2) 托管来宾的 qvm 是否必须包含相关的 vdev
(3) 如果来宾需要知道它正在虚拟化环境中运行

在非虚拟化系统中，操作系统中的设备驱动程序必须与物理板上的硬件设备相匹配。 在虚拟化系统中，guest 中的设备驱动程序必须与 vdev 匹配。

例如，如果您使用的是 vdev-pl011 vdev（配置如下：vdev vdev-pl011 loc 0x1c090000 intr gic:37）， 则必须告诉您的客户机使用位置 0x1c090000 处的 PL011 设备和中断 37。

您无法传递使用 UART 设备的来宾指令（例如 Earlycon=msm_hsl_uart,0x75b0000），并期望它找到 PL011 设备，就像在非虚拟化环境中那样。

有关配置虚拟机管理程序主机、qvm 进程和设备的信息，请参阅 “Configuration” 一章。

7.1 Physical devices

物理设备可以供虚拟机管理程序主机或来宾专用，也可以被共享。

虚拟化环境中的物理设备（或简称设备）与非虚拟化环境中的设备完全相同。 它们需要驱动程序，并且它们断言中断并接收信号等。

在 QNX 虚拟化环境中运行的来宾可以直接或通过虚拟设备访问物理设备，也可能被禁止访问设备。 对物理设备的访问由虚拟化环境的配置控制。 物理设备可以配置为：

(1) 专供特定客人使用（请参阅本章“Pass-through devices”）
(2) 客人之间共享； 并非所有设备都可以共享（请参阅本章“Shared devices”）

1. 直通设备

在虚拟机管理程序系统中，直通设备是访客可以直接且独占访问的物理设备。 这种对物理设备的访问可能比通过虚拟设备的访问更快，或者比与其他来宾或管理程序主机共享访问更快。

要使用直通设备，来宾必须拥有自己的物理设备驱动程序。 托管 guest 虚拟机的 qvm 进程不需要 vdev，虚拟机管理程序本身也不需要驱动程序。

对于直通设备，管理程序主机域只知道它必须将中断从物理设备直接路由到来宾， 并将信号从来宾直接传递到设备。 所有交互均发生在访客和设备之间； 虚拟机管理程序的唯一职责是识别并允许通过来自设备的中断以及来自来宾的信号。

图 1. 虚拟机管理程序系统中直通设备的图示。

在启动 guest 虚拟机之前，必须在将托管 guest 虚拟机的 VM 的 *.qvmconf 文件中配置直通设备（请参阅“VM Configuration Reference” 一章中的“pass”）。

一般而言，在任一时间仅允许虚拟化系统的一名驻留者访问直通设备。如果主机拥有来宾需要作为直通设备的设备，则主机必须先终止设备驱动程序，然后来宾才能在其虚拟环境中启动该设备的驱动程序。

类似地，如果一个来宾拥有一个设备作为直通设备，则它必须在其虚拟化空间中终止该设备驱动程序，然后另一来宾才能在其空间中使用该设备。

简而言之，您永远不应该将 DMA 设备传递给多个来宾，只有在特殊设计中才应将非 DMA 设备传递给多个来宾。

如果您认为您的设计需要将非 DMA 设备传递给多个来宾，请联系您的 QNX representative。

1.1 直通时钟相关设备

时钟相关设备（例如 eMMC）可能需要传递额外的工作，因为来宾无法访问时钟。 通过这些设备的策略包括：

(1) 修改来宾设备驱动程序，使其不会尝试修改时钟。
(2) 创建一个 vdev，当来宾设备尝试操纵时钟时进行干预。
(3) 如果时钟寄存器间隔适当，则将时钟寄存器的适当子集传递给客户机。

如需了解更多信息，请联系您的 QNX representative。

1.2 处理复杂设备的直通

某些设备（例如音频和视频设备）由多个硬件接口组成，需要非常特定的配置才能正确运行。

知识渊博的系统设计人员知道并理解如何使用所有设备接口，并且可以在 VM 配置中正确定义它们，应该能够使任何复杂的设备作为 QNX 虚拟机管理程序系统中的直通设备工作。

请联系 QNX 服务部门，了解有关在客人之间共享复杂设备的更多信息。

2. 共享设备

在虚拟机管理程序系统中，共享设备是可由多个来宾使用，或者由一个或多个来宾和虚拟机管理程序本身使用的物理设备。 有多种方法（例如 VIRTIO）和模型可用于设备共享； 这些包括：

(1) Referred sharing
(2) Mediated sharing

虚拟机管理程序提供 TCP/IP、共享内存和 virtqueue 支持等服务，可用于设备共享。 您实施的服务和配置将取决于您的系统的要求。

QNX 虚拟机管理程序支持可共享音频和图形物理设备的 vdev。 如需了解更多信息，请联系您的 QNX 代表。

2.1 Referred sharing

通过引用的共享模型，要共享的物理设备被分配给具有设备完全控制权的访客。 如果物理设备作为直通设备进行访问，则访客需要物理设备的驱动程序（请参阅上面的“Pass-through devices”）。 如果通过虚拟设备访问物理设备，则托管 guest 虚拟机的 qvm 进程必须具有适当的虚拟设备（请参阅本章中的“Virtual devices”），并且 guest 虚拟机和虚拟机管理程序主机都需要适当的设备驱动程序： 虚拟化设备（来宾）和实际物理设备（主机）。

必须访问物理设备的其他来宾使用 TCP 或共享内存和虚拟队列等机制来与控制设备的来宾进行通信，并根据需要传递数据。

例如，假设两个来宾正在虚拟机管理程序系统上运行。 Guest 0 是与 QNX 安全相关的 guest 虚拟机，而 Guest 1 是没有安全要求的普通 Linux 操作系统 guest 虚拟机。 他们都需要访问设备来输出音频：Guest 0 发出警告声音，Guest 1 播放音乐。

我们将音频设备作为直通设备分配给 Guest 0。托管 Guest 1 的 VM 的 qvm 进程中的音频虚拟设备旨在与另一个 VM 中的虚拟设备共享数据，并且它被配置为知道此 其他虚拟设备位于托管 Guest 0 的 VM 的 qvm 进程中。使用此配置，Guest 1 的所有音频设备活动都将参考 Guest 0 进行处理。

当Guest 0的qvm进程中的虚拟设备接收到Guest 1的中断和数据时，它将它们传递给Guest 1的qvm中的虚拟设备； 当Guest 1的qvm进程中的虚拟设备从Guest 1接收到音频设备的信号和数据时，它会将这些信号和数据传递给Guest 0，以传递给其音频设备驱动程序，并最终传递给物理音频设备。

由于Guest 0控制来自音频设备的所有输入和输出，因此它可以设置优先级以确保与安全相关的进程和线程优先于普通操作系统及其应用程序的输入和输出，甚至拒绝与其他guest合作 或者如果合作可能会危及其自身的安全相关活动，则与设备合作。

使用由另一个访客控制的物理设备的访客依赖于该另一个访客来访问该设备； 如果由于任何原因控制设备的访客不可用，则该设备也将变得不可用。 因此，如果访客正在关闭，它应该通知使用其控制的任何设备的任何其他访客该设备现在不可用。

2.2 Mediated sharing

中介共享模型与引用共享模型类似。 不同之处在于，对于中介模型，是虚拟机管理程序主机进程而不是来宾承担控制与物理设备的接口并确保尊重配置的优先级的责任。

使用此模型，要共享的设备被分配给虚拟机管理程序本身。 每个 VM 的 qvm 进程中的虚拟设备连接到虚拟机管理程序中的中介器。 该中介器确定哪些中断和数据从物理设备传递到来宾，以及哪些信号和数据从来宾传递到管理程序中的设备驱动程序，并最终传递到物理设备。

调解器还确保配置的优先级得到尊重（例如，确保与安全相关的活动优先），甚至拒绝与其活动可能对系统上的其他来宾或管理程序本身有害的来宾或设备合作。

中介进程不一定必须驻留在管理程序主机中。 他们可以住在其中一位客人的房间里。 但请注意，通过此设计，来宾故障将导致中介共享的未定义行为。

7.2 Virtual devices

虚拟设备可以模拟物理设备，或者它可以提供类似于物理设备所提供的功能，而不模拟任何特定的物理设备。

虚拟设备（或 vdev）仅存在于虚拟化环境中。 要使用 vdev，客户机需要一个驱动程序，就像在非虚拟化环境中使用物理设备需要驱动程序一样。

vdev 可能永远不会访问物理设备，或者它可以充当直接响应来宾并在来宾和物理设备之间传递请求和响应的中介。

在虚拟机管理程序系统中，虚拟机管理程序在 qvm 进程中为托管来宾的 VM 提供 vdev。 VM 中托管的来宾接收来自 vdev 的中断并向其发送信号，就像它正在使用物理硬件设备一样。 访客与系统上的任何物理设备没有直接通信； 这样的设备甚至可能不存在。

来宾需要为其将使用的每个 vdev 提供一个设备驱动程序。

虚拟机管理程序支持以下类型的 vdev：

(1) Emulation vdevs --仿真虚拟设备
(2) Para-virtualized devices --半虚拟化设备

有关如何编写自己的虚拟设备的信息，请参阅 “Virtual Device Developer's Guide”。

1. 仿真虚拟设备

仿真 vdev（或简称 vdev）是为来宾模拟实际物理设备的虚拟设备。 以下是 QNX 虚拟化环境中仿真 vdev 的主要特征：

(1) 要使用 vdev，来宾不需要知道它正在虚拟化环境中运行。 它与这些设备的交互方式与与物理设备的交互方式完全相同，并且没有迹象表明它正在与虚拟设备一起工作，或者可能不涉及任何硬件设备。

(2) vdev 模拟物理设备。 事实上，某些 vdev（例如 x86 pckeyboard）的存在仅仅是因为在 x86 平台上运行的来宾希望它们存在。

(3) 模拟的物理设备可能存在于系统上，也可能不存在。

(4) 根据物理设备的类型，仿真 vdev 可以自己处理所有事情（例如，仿真计时器芯片 (vdev-timer8254)），也可以充当来宾和实际物理设备之间的中介（例如，vdev- Ser8250）。

(5) 如果虚拟设备在非虚拟化环境中运行，则来宾可以为 vdev 使用与模拟物理设备相同的设备驱动程序。

图 1. 虚拟机管理程序系统中的仿真 vdev 的图示。

2. 半虚拟化设备

半虚拟化设备是虚拟设备的一种。 它们是在虚拟机管理程序层中运行的软件代码，但该代码不模拟任何特定的硬件设备。

相反，半虚拟化设备提供了非虚拟化环境中一个物理设备（或多个物理设备）可能提供的功能，但不受模拟硬件的限制。

典型的半虚拟化设备需要在客户（前端）中运行代码，在客户之外（后端）运行代码； 例如，在来宾中运行的文件系统设备驱动程序连接到在虚拟机管理程序主机中运行的块设备驱动程序。

半虚拟化设备的主要特征包括：

(1) 要使用半虚拟化设备，来宾必须知道它正在虚拟化环境中运行。 例如，要使用 virtio-net，来宾必须知道它正在虚拟化环境中运行，即使只是因为 virtio-net 没有相应的物理设备（它仅作为半虚拟化设备存在）。

(2) 不存在与半虚拟化设备完全对应的物理设备。

(3) 来宾必须具有适当的驱动程序和接口才能与半虚拟化设备配合使用。

图 2. 虚拟机管理程序系统中的半虚拟化设备的图示。

半虚拟化设备需要一些初始投资（例如，为来宾编写驱动程序），但这些设备通常可能比必须模拟硬件组件的 vdev 更高效。 例如，模拟提供控制台终端的串行端口接口可能会导致许多访客退出和返回。 virtio-console vdev（半虚拟化串行端口接口）提供相同的功能，但来宾系统的开销更少。

半虚拟化设备不一定是 VIRTIO 设备； VIRTIO 只是一个方便且当前流行的标准。

八、Scheduling

了解调度如何影响 QNX 虚拟化环境中的系统行为非常重要。

8.1 管理程序线程优先级和来宾线程优先级

与任何高级软件系统一样，要在具有 QNX 虚拟机管理程序的系统中正确配置调度优先级，需要全面了解您的系统要求和系统功能。

首先，您应该记住以下几点：

(1) 虚拟机管理程序主机不知道其虚拟机中正在运行什么，也不知道来宾如何调度自己的内部软件。 当您在来宾操作系统中设置优先级时，这些优先级只有该来宾知道。

(2) 虚拟CPU（vCPU）由qvm vCPU调度线程调度； 这些线程存在于虚拟机管理程序主机域中。

(3) 来宾中的线程优先级与虚拟机管理程序主机中的线程优先级无关。 qvm进程vCPU调度线程的相对优先级决定了哪个vCPU可以访问物理CPU。

下图说明了来宾内部的优先级仅在来宾内部相关，并且对于两个竞争来宾中的哪一个访问物理 CPU 没有影响。阴影区域显示两个竞争 vCPU 线程中的哪一个可以访问物理 CPU。

图 1. 访问物理 CPU 的重要优先级是 qvm 进程的 vCPU 线程的优先级。

如果两个 vCPU 竞争单个物理 CPU (pCPU)，则优先级较高的 vCPU 线程会立即访问物理 CPU。 来宾内部运行的线程的优先级对此访问没有影响。 在上图所示的例子中：

(1) Guest 1 中的线程比 Guest 0 中的线程具有更高的优先级。

(2) 为 Guest 0 提供 vCPU 的虚拟机管理程序线程的优先级 (200) 高于为 Guest 1 提供 vCPU 的虚拟机管理程序线程 (100)。

(3) 因此，内部Guest 0线程获得对物理CPU的访问权，并从时间0开始运行，直到它自愿放弃物理CPU。

(4) 结果是内部Guest 1线程被阻塞，直到Guest 0中的线程自愿阻塞。

简而言之，确定优先级就是qvm进程的vCPU调度线程的优先级。

8.2 客人退出

以下情况会导致访客退出：

(1) 客人停下来

vdev 访问权限； 这种退出并不一定会导致 guest 虚拟机放弃对 CPU 的控制，因为 guest 虚拟机的 vCPU 线程不一定会阻塞

主机上的中断，包括处理器间中断 (IPI)

虚拟计时器，例如模拟 Intel 8254 芯片的 vdev

一条指令，例如CPUID指令

有关来宾退出及其对虚拟机管理程序系统性能影响的更多信息，请参阅 “Performance Tuning” 一章。 有关 QNX 操作系统中调度的更多信息，请参阅 QNX Neutrino 系统架构中的 “Thread scheduling” 。

九、Interrupts

在 QNX 虚拟机管理程序系统中，来宾配置其虚拟可编程中断控制器 (PIC)，虚拟机管理程序根据这些配置管理中断。

虚拟机管理程序主机必须进行干预，以管理硬件发出的任何中断，无论谁的操作触发了中断，或者谁拥有发出中断的设备，或者中断的最终目的地。 这意味着需要客户出口，以便管理程序可以识别中断的目的地，执行任何所需的处理，并将中断传递到其目的地。

有关如何减少管理程序系统中处理中断所需的开销的信息，请参阅 “Performance Tuning” 一章。

9.1 虚拟机管理程序主机的中断

仅发往虚拟机管理程序主机的中断包括来自虚拟机管理程序拥有的设备的中断以及物理 CPU 之间的 IPI。 这些中断由管理程序微内核中断处理机制处理，就像非虚拟化 QNX 操作系统中的中断一样（请参阅 QNX Neutrino 入门中的“Interrupts”）。 您不需要对这些特定于虚拟机管理程序系统的中断执行任何操作。

9.2 客户机的中断

对来宾的中断的处理由 QNX Neutrino 微内核 (procnto) 和托管来宾的 VM（qvm 流程实例）共享。

QNX Neutrino 微内核

微内核负责以下工作：

(1) 保存被中断的 guest 虚拟机的上下文（ARM 和 x86 通用的 build_host.xml 代码）

(2) 识别中断（PIC 特定标注）

(3) 屏蔽中断（PIC 特定的标注）

(4) 通知相关的 qvm 进程实例，该中断可用于传递给 guest 虚拟机（ARM 和 x86 通用的 build_host.xml 代码）

相关的 qvm 流程实例负责以下内容：

(1) 向来宾传送虚拟中断（如果可用，可以使用特定于 PIC 的硬件辅助例程）

(2) 检测来宾已处理中断（ARM 和 x86 通用的 build_host.xml 代码）

(3) 取消屏蔽中断（请参阅《QNX Neutrino C 库参考》中的 InterruptUnmask()）。

qvm 进程不会取消屏蔽中断，直到 guest 虚拟机处理完中断为止。 这种设计确保如果 guest 虚拟机在处理中断时出错，该错误不会影响虚拟机管理程序本身或其他 guest 虚拟机。 简而言之，虚拟机管理程序可以免受由来宾错误引起的中断风暴的影响。

但是，虚拟机管理程序无法保护来宾免受其自身的侵害。 如果 guest 虚拟机没有正确清除中断条件，或者中断率太高，guest 机将把时间花在自己的中断处理代码上，并且无法在 vCPU 上运行用户线程。 如果来宾在非虚拟化环境中运行，就会发生这种情况。

9.3 中断优先级和目的地

来宾操作系统配置自己的中断优先级和目标，就像在非虚拟化环境中运行一样。 虚拟机管理程序在托管来宾的 VM 中提供虚拟 GIC (ARM) 或 APIC (x86)（请参阅 “Virtual Device Reference” 一章中的 vdev gic 和 vdev ioapic）。

对于客户来说，这些虚拟中断控制器与硬件 GIC 或 APIC 没有区别。 虚拟机管理程序根据优先级将中断传送到 vCPU 并传送到访客配置的目的地。 例如，QNX 来宾期望中断发送至物理 CPU 0，因此虚拟机管理程序将中断传递至托管来宾的 VM 中的 vCPU 0。

9.4 来宾启动和关闭期间的中断

托管来宾的 qvm 流程实例会屏蔽发往该来宾的中断，直到来宾成功启动并启动相应的设备驱动程序。 类似地，当来宾开始其关闭过程时，托管 qvm 流程实例会屏蔽针对该来宾的中断。

十、Time

在 QNX 虚拟机管理程序上运行的来宾中的时间始终落后于主机中的时间， 但虚拟机管理程序会采取纠正措施来最大限度地减少这种滞后（或漂移）。

10.1 漂移

虚拟机管理程序系统中的来宾时间是虚拟化的。 也就是说，托管来宾的 VM（qvm 流程实例）提供虚拟计时器滴答声以及来宾期望在其环境中找到的虚拟硬件计时器。 因此，管理程序主机控制每个来宾看到的时钟。 当访客退出时，虚拟机管理程序主机对访客时钟所做的操作对访客有重大影响，特别是对访客的时间预算。 当访客退出时，管理程序主机可以让访客时钟运行或停止访客时钟。 这些选项都不是理想的。

1. 访客时钟在退出期间运行

如果虚拟机管理程序主机允许来宾时钟运行，则来宾时钟将与主机时钟保持同步，仅通过偏移量分隔，偏移量是主机开始计数时间与来宾开始计数时间之间经过的时间（请参阅下面的“Offset”）。

然而，允许时钟运行会扭曲访客的时间统计，因为访客退出和重新进入之间的时间段会添加到访客需要退出的任务所耗用的时间中。 例如，任务可能会耗尽其时间预算并被抢占，而除了退出之外实际上没有做太多事情。

2. 访客时钟在退出时停止

当客人退出时停止客人的时钟解决了退出扭曲客人的时间预算的问题。 当来宾退出时，来宾时钟将停止，直到来宾重新进入，并且来宾仅根据任务的时间预算记录其实际运行的时间。 然而，随着客人的时钟停在每个客人出口处，该时钟越来越落后于主人的时钟。 这种滞后称为漂移。

在每个客人出口处，漂移都会增加。 如果允许漂移增加而不加纠正，来宾很快就会遇到可能阻止其按要求运行的情况：来宾可能会错过计时器中断，一天中的时间将越来越不准确，等等。

请注意，为了保持来宾 vCPU 的时间戳计数器同步，虚拟机管理程序仅在托管来宾的 VM 中的所有 vCPU 都退出时才停止来宾的时钟。

10.2 跳跃

为了让客人合理控制他们的时间预算，QNX 虚拟机管理程序会在每次客人退出时停止客人的时钟，并在客人进入时重新启动时钟（请参阅“架构”中的 Lahav 线）。 然而，为了减轻漂移的影响并避免未纠正的漂移最终产生的问题，QNX 虚拟机管理程序会定期导致来宾中的时间向前跳跃； 也就是说，它将客人的时间设置为当前漂移的一部分。

虚拟机管理程序仅向前跳过来宾和主机之间的延迟的一部分，因为向前跳过来宾中的时间会扭曲来宾的时间计算。

例如，考虑一个比主机落后 10 微秒的客户机。 该来宾现在正在运行 foo。 如果虚拟机管理程序将来宾时间向前跳过完整的 10 微秒，则这 10 微秒（foo 未使用的）仍将计入 foo，因为 foo 开始时间和结束时间之间的增量包括向前跳过的 10 微秒。 因此，管理程序仅向前跳过访客时间漂移的一部分，以在访客的活动中更均匀地分配跳跃。

如果您在客人中实施了任何类型的时间预算，您应该考虑漂移和纠正跳过对这些预算的影响。 特别要记住：

(1) 仅当来宾退出其所有 vCPU 时才可以跳过，因此跳过必然以不规则的间隔发生。

(2) 虚拟机管理程序主机一有机会就会跳过来宾的时间。

(3) 管理程序主机仅向前跳过当前漂移的一部分。

(4) 总会有一些漂移，并且这种漂移在客户机的生命周期中变化。

由于只有当所有 vCPU 线程都退出时才能进行跳跃 ，因此管理程序会尝试尽早唤醒等待中断的 vCPU 线程，以便它们全部退出并允许跳过。

有关如何检索访客当前时间偏差的信息，请参阅 “Monitoring and Troubleshooting” 一章中的 “Finding the current time drift”。

10.3 Offset

来宾只能在主机启动后启动，因此来宾必须比其主机晚开始计数（在管理程序系统外部测量）。 这种差异只是一种偏移，与漂移的关系仅在于它与时间有关。

10.4 墙上时钟

虚拟机管理程序提供了各种机制，您可以使用这些机制来保持来宾中的挂钟与虚拟机管理程序主机的时钟保持一致。 其中包括从外部源获取时间，以及使用共享内存来比较挂钟并在必要时触发更新以对齐它们（有关如何连接来宾系统的信息，请参阅 “Using a QNX Hypervisor System” ”一章中的 “Networking” ） 以及同一章中的 “Memory sharing”，了解有关如何在来宾和虚拟机管理程序主机之间设置内存共享的信息）。

十一、 Sharing resources

在虚拟机管理程序系统中，除了小部分共享内存之外，内存和设备均由单个实体（来宾或虚拟机管理程序主机）独占所有。

在不同虚拟机中运行的多个来宾可以使用相同的系统资源，例如物理CPU。 这些资源的管理完全属于虚拟机管理程序的范围。 系统集成商的职责仅限于（非常重要）为每个虚拟机配置适当数量的 vCPU、设置其优先级以及将 vCPU 线程绑定（固定）binding (pinning) 到特定物理 CPU（如果需要）上 (见 “Performance Tuning” 中的 “SMP” 章节)。

其他资源（例如内存和物理设备）通过虚拟机配置分配给特定的虚拟机，管理程序使用虚拟机配置来组装虚拟机（请参阅“Configuration”一章）。 这些资源成为每个虚拟机中运行的来宾的专有财产。 它们不能在来宾之间共享，就像不能在两个单独的板上共享物理设备一样。

11.1 共享内存

当您为 VM 配置 RAM 和 ROM 时，让 qvm 进程选择内存的主机物理地址通常是最佳策略，因为该进程不会将相同的内存位置分配给多个 VM。

然而，小型共享内存区域可以成为在不同虚拟机中的来宾之间传递数据的有效机制。 如果需要配置共享内存区域，可以使用 vdev（例如 vdev-shmem）来利用虚拟机管理程序的共享内存服务。 有关如何实现以及如何使用共享内存的更多信息，请参阅 “Using a QNX Hypervisor System” 一章中的 “Memory sharing”。

11.2 共享设备

与内存一样，设备不能直接共享。 虚拟设备（无论是仿真还是半虚拟化）要么是隐式的（在 qvm 进程代码中），要么是配置到 VM 中的共享对象； 因此它们是虚拟机独有的。  物理设备要么作为直通设备直接分配给来宾，要么分配给虚拟机管理程序主机，并由来宾通过虚拟设备访问。

如果物理设备所有者以外的实体需要访问该设备，则必须通过设备所有者， 就像设备物理上位于另一块板上一样。 如果设备由虚拟机管理程序主机拥有，则称为中介共享； 如果它由另一位客人拥有，则称为推荐共享。 有关详细信息，请参阅本章中的“共享设备”。