在QNX hypervisor系统中，guests配置其虚拟可编程中断控制器（PICs virtual Progammable Interrupt Controllers），hypervisor 根据这些配置管理中断。
hypervisor 主机必须进行干预，以管理硬件断言的任何中断，无论是谁的操作触发了中断，还是谁拥有断言中断的设备，或者中断的最终目的地。这意味着需要一个guest 出口，以便hypervisor 能够识别中断的目的地，执行任何所需的处理，并将中断传递到其目的地。
有关如何减少hypervisor 系统中处理中断所需的开销的信息，参考Performance Tuning章节。
hypervisor主机的中断
仅针对hypervisor 主机的中断包括来自hypervisor 拥有的设备的中断，以及物理 CPU 之间的 IPI。 这些中断由管理程序微内核中断处理机制处理，就像非虚拟化 QNX 操作系统中的中断一样。(参考Getting Started with QNX Neutrino中的Interrupts)。 对于hypervisor 系统特定的这些中断，您无需执行任何操作。
guests中的中断
QNX Neutrino 微内核 (procnto) 和托管来宾的 VM（qvm 进程实例）共享处理发往guest的中断。
QNX Neutrino microkernel
微内核负责以下内容：
- 保存guest中断的上下文（ARM 和 x86 通用的 build_host.xml 代码）
- 识别中断（PIC-specific callouts）
- 标记中断（PIC-specific callouts）
- 通知相关的 qvm 进程实例中断可用于传递给guest（ARM 和 x86 通用的 build_host.xml 代码）
相关qvm进程实例负责以下内容：
- 向guest提供虚拟中断（如果可用，可以使用特定于 PIC 的硬件辅助例程）
- 检测guest已经处理了的中断（ARM 和 x86 通用的 build_host.xml 代码）
- 取消中断屏蔽(参考 QNX Neutrino C Library Reference中的 InterruptUnmask())。
qvm 进程在guest处理中断之前不会取消屏蔽中断。 这种设计确保如果guest在处理中断时出错，该错误不会影响hypervisor 本身或其他guest。 简而言之，hypervisor 可以避免由guest错误引起的中断风暴。 但是，hypervisor 无法保护guest免受其自身的侵害。 如果guest没有正确清除中断条件，或者中断率太高，客户机将把时间花在自己的中断处理代码上，并且无法在 vCPU 上运行用户线程。 如果guest在非虚拟化环境中运行，就会出现这种行为。
中断优先级和目的地
guest操作系统配置自己的中断优先级和目的地，就像它们在非虚拟化环境中运行一样。 hypervisor 在托管来宾的 VM 中提供虚拟 GIC (ARM) 或 APIC (x86) (参考“Virtual Device Reference”章节的vdev gic和 vdev ioapic )。
对于guest来说，这些虚拟中断控制器与硬件 GIC 或 APIC 没有区别。 hypervisor 根据优先级和guest配置的目的地向 vCPU 传送中断。 例如，QNX guest希望中断转到物理 CPU 0，因此hypervisor 将中断传递给托管guest的 VM 中的 vCPU 0。
启动和关机过程中的中断
托管guest的 qvm 进程实例会屏蔽去往该guest 的中断，直到来宾成功启动，并启动适当的设备驱动程序。 类似地，当guest开始其关闭程序时，托管 qvm 进程实例会屏蔽为该guest 准备的中断。
