QNX hypervisor 为guests提供对物理设备（包括pass-through和共享设备）和虚拟设备（包括仿真和para-virtualized设备）的访问权限。
About device access
配置 QNX 虚拟化环境（hypervisor、虚拟机的 qvm 进程和guests）时，您需要将物理设备和虚拟设备 （vdev） 分配给hypervisor 和guests。 要正确执行此操作，您不仅需要知道设备是物理设备还是虚拟设备，还需要知道物理设备或虚拟设备的类型，因为这决定了：
- 如果guest或hypervisor 必须包含设备驱动程序
- 如果托管guest的 QVM 必须包含相关的vdev
- 如果guest需要知道它正在虚拟化环境中运行
在非虚拟化系统中，操作系统中的设备驱动程序必须与物理板上的硬件设备匹配。在虚拟化系统中，guest 中的设备驱动程序必须与 vdev 匹配。 例如，如果您使用的是 vdev-pl011 vdev（配置如下：vdev vdev-pl011 loc 0x1c090000 intr gic：37），则必须告诉您的guest 在位置 0x1c090000 使用 PL011 设备并中断 37。 你不能通过你的guest 指令来使用UART设备，比如earlycon=msm_hsl_uart，0x75b0000，并期望它找到PL011设备，就像你在非虚拟化环境中那样。
有关配置hypervisor 主机、qvm 进程和设备的信息，参考Configuration章节。
Physical devices
物理设备可以供hypervisor 主机或guest独占使用，也可以共享。 虚拟化环境中的物理设备（或简称设备）与非虚拟化环境中的设备完全相同。它们需要驱动程序，并且它们断言中断并接收信号等。
在 QNX 虚拟化环境中运行的guest可以直接或通过虚拟设备访问物理设备，也可能被禁止访问设备。对物理设备的访问由虚拟化环境的配置控制。物理设备可以配置为：
- 仅限特定guest 使用（参考Pass-through devices）
- guests之间共享;并非所有设备都可以共享(参考Shared devices)
Pass-through devices
在hypervisor 系统中，pass-through设备是guest具有直接和独占访问权限的物理设备。 这种类型的物理设备访问可能比通过虚拟设备访问更快，或者比其他guests 或hypervisor主机共享访问更快。
若要使用pass-through设备，guest 必须具有自己的物理设备驱动程序。托管guest的 qvm 进程中不需要 vdev，虚拟机管理程序本身也不需要驱动程序。
对于pass-through设备，hypervisor主机域只知道它必须将中断从物理设备直接路由到guest，并将信号从guest直接传递到设备。
所有交互都在guest 和设备之间进行;
hypervisor的唯一职责是识别并允许通过来自设备的中断和来自guest的信号。
在启动guest 之前，必须在将托管guest 的 VM 的 *.qvmconf 文件中配置pass-through设备（参考VM Configuration Reference章节的pass）
通常，在任何时候只允许虚拟化系统的一个驻留者访问pass-through设备。如果主机拥有guest需要作为传递设备的设备，则主机必须先终止设备驱动程序，然后guest才能在其虚拟环境中启动设备的驱动程序。 同样，如果一个guest拥有作为传递设备的设备，则它必须在其虚拟化空间中终止此设备驱动程序，然后另一个guest才能在其空间中使用该设备。 简而言之，切勿将 DMA 设备传递给多个guest ，并且只有在特殊设计中，才应将非 DMA 设备传递给多个guest 。 如果您认为您的设计需要将非 DMA 设备传递给多个guest ，请联系您的QNX representative
Passing through 时钟相关设备
与时钟相关的设备（例如 eMMC）可能需要额外的工作才能通过，因为guest 无法访问时钟。passing through这些设备的策略包括：
- 修改guest的设备驱动程序，使其不会尝试修改时钟。
- 创建一个 vdev，当guest 的设备尝试操作时钟时进行干预。
- 如果时钟寄存器的间隔适当，请将时钟寄存器的相应子集传递给guest 。
处理复杂设备的pass-through
某些设备（例如，音频和视频设备）由多个硬件接口组成，并且需要非常具体的配置才能正常运行。 知识渊博的系统设计人员，知道如何使用所有设备接口，并能在虚拟机配置中正确定义这些接口，应该能够使任何复杂的设备在 QNX hypervisor 系统中作为pass-through设备工作。
共享设备
在hypervisor 系统中，共享设备是可由多个guest或一个或多个guest和hypervisor本身使用的物理设备。 有几种方法（例如，VIRTIO）和模型可用于设备共享;其中包括：
hypervisor 提供 TCP/IP、shared memory存和 virtqueue 支持等服务，您可以使用这些服务进行设备共享。您实施的服务和配置将取决于系统的要求。
QNX 虚拟机管理程序支持 vdev，支持共享音频和图形物理设备。 更多信息，请联系您的QNX representative
Referred sharing
使用referred sharing模型，要共享的物理设备将分配给guest，guest可以完全控制设备。 如果物理设备作为pass-through设备访问，则guest需要物理设备的驱动程序（请参阅上面的Pass-through devices）。 如果通过虚拟设备访问物理设备，则托管guest的 qvm 进程必须具有适当的虚拟设备（请参阅本章中的Virtual devices），并且guest和hypervisor 主机都需要适当的设备驱动程序：用于虚拟化设备（guest）和实际物理设备（host）。
必须访问物理设备的其他guest 使用 TCP 或共享内存和虚拟队列等机制与控制设备的guest 通信，并根据需要传递数据。
例如，假设两个guest 在hypervisor 系统上运行。Guest 0 是 QNX safety-related访客，而Guest 1 是garden-variety Linux 操作系统访客，没有安全要求。它们都需要访问设备才能输出音频：Guest 0 发出警告声音，Guest 1 播放音乐。
我们将音频设备作为pass-through设备分配给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 控制音频设备的所有输入和输出，因此它可以设置优先级以确保与safety-related的进程和线程优先于garden-variety操作系统及其应用程序的输入和输出，如果合作可能危及其自身的安全相关活动，甚至可以拒绝与其他guest或设备合作。
使用由另一个guest 控制的物理设备的guest依赖于该其他guest访问该设备; 如果由于任何原因控制设备的客户机变得不可用，则设备也将变得不可用。因此，如果guest正在关闭，它应通知使用它控制的任何设备的任何其他guest 该设备现在不可用。
Mediated sharing
mediated sharing模型类似于referred sharing模型。不同之处在于，对于mediated 模型，是hypervisor 主机进程而不是guest承担控制与物理设备的接口并确保遵守配置的优先级的责任。
使用此模型，要共享的设备将分配给hypervisor 本身。每个虚拟机的 qvm 进程中的虚拟设备连接到hypervisor 中的mediator 。 此mediator 确定哪些中断和数据从物理设备传递到guests，以及哪些信号和数据从guest传递到hypervisor中的设备驱动程序，并最终传递到物理设备。 mediator 还确保配置的优先级得到尊重（例如，确保与安全相关的活动优先），甚至拒绝与活动可能对系统上的其他guests 或hypervisor 本身有害的guests 或设备合作。
mediator 进程不一定必须驻留在hypervisor主机中。 他们可以住在其中一位guests身上。但请注意，使用此设计时，guests故障将导致mediated sharing出现未定义的行为。
Virtual devices
虚拟设备可以模拟物理设备，也可以提供物理设备提供的功能，而无需模拟任何特定的物理设备。
虚拟设备（或 vdev）仅存在于虚拟化环境中。若要使用 vdev，guests需要驱动程序，就像需要驱动程序在非虚拟化环境中使用物理设备一样。
vdev 可能永远不会访问物理设备，或者它可能充当中介，既直接响应guests，又在guests和物理设备之间传递请求和响应。
在hypervisor 系统中，hypervisor在 qvm 进程中为托管guest的虚拟机提供。 VM 中托管的guest接收来自 vdev 的中断并向其发送信号，就像它正在使用物理硬件设备一样。guest与系统上的任何物理设备没有直接通信;这样的设备甚至可能不存在。
guest 需要为其将使用的每个 vdev 提供设备驱动程序。 hypervisor 支持以下类型的 vdev：
有关如何编写自己的 vdev 的信息,参考 Virtual Device Developer’s Guide
Emulation vdevs
仿真 vdev（或简称 vdev）是一种虚拟设备，用于模拟guest的实际物理设备。以下是 QNX 虚拟化环境中仿真 vdev 的主要特征：
- 要使用 vdev，guest 无需知道它是否在虚拟化环境中运行。它与这些设备的交互与物理设备完全相同，并且没有迹象表明它正在使用虚拟设备，或者可能不涉及硬件设备。
- vdev 模拟物理设备。事实上，某些 vdev（例如 x86 pckeyboard）的存在仅仅是因为在 x86 平台上运行的guest 希望它们在那里。
- 模拟的物理设备可能存在于系统上，也可能不存在。
- 根据物理设备的类型，仿真 vdev 可以自己处理所有内容（例如，仿真定时器芯片 （vdev-timer8254）），也可以充当guest 和实际物理设备之间的中介（例如，vdev-ser8250）。
- guest 可以对 vdev 使用与模拟物理设备（如果在非虚拟化环境中运行时）相同的设备驱动程序。
Para-virtualized devices
半虚拟化设备是一种虚拟设备。它们是在hypervisor 层中运行的软件代码，但此代码不模拟任何特定的硬件设备。 相反，半虚拟化设备提供的功能可能由非虚拟化环境中的物理设备（或多个物理设备）提供，但没有模拟硬件的限制。
典型的半虚拟化设备要求代码在guest（前端）中运行，代码在guest外部运行（后端）; 例如，在客户机中运行的文件系统设备驱动程序连接到在hypervisor主机中运行的块储存设备驱动程序。
半虚拟化设备的主要特征包括：
- 要使用半虚拟化设备，guest 必须知道它正在虚拟化环境中运行。例如，要使用virtio-net，guest必须知道它正在虚拟化环境中运行，如果仅仅是因为virtio-net没有相应的物理设备（它仅作为半虚拟化设备存在）。
- 不存在与半虚拟化设备完全对应的物理设备。
- guest 必须具有适当的驱动程序和接口才能使用半虚拟化设备。
半虚拟化设备需要一些初始投资（例如，为guests编写驱动程序），但这些设备通常可能比必须模拟硬件组件的 vdev 更有效。例如，模拟提供控制台终端的串行端口接口可能会导致许多guest 退出和返回。virtio-console vdev（半虚拟化串行端口接口）提供相同的功能，但guests的开销更少。
半虚拟化设备不一定是 VIRTIO 设备;VIRTIO 只是一个方便且当前流行的标准。
