2. 虚拟化与Xen基础
在进入 Xen 设备直通与资源隔离的工程实践之前，必须先建立一张清晰的“虚拟化地图”。只有理解了虚拟化类型、Hypervisor 的职责边界、Xen 的架构分层，以及 Domain 0 与 Domain U 的角色分工，后续讨论 PCI 直通、IOMMU、中断重映射时，才不会把“谁在管硬件、谁在管虚拟机”混为一谈。本节围绕这条主线展开，并为 PV 与 HVM 两种模式建立可对比的认知框架。
一、虚拟化类型：从全虚拟化到半虚拟化
虚拟化的本质，是在同一套物理硬件上抽象出多个彼此隔离的执行环境。按实现方式，常见分类如下：
- 全虚拟化（Full Virtualization）：Guest OS 无需修改，由 Hypervisor 通过二进制翻译或硬件辅助（Intel VT-x / AMD-V）捕获敏感指令并模拟。优点是兼容性好，缺点是早期性能开销较大。
- 半虚拟化（Paravirtualization, PV）：Guest OS 需要修改内核，主动通过 hypercall 与 Hypervisor 协作。优点是 I/O 与特权操作路径短、性能好，缺点是需要定制内核。
- 硬件辅助虚拟化（HVM）：CPU 提供根模式与非根模式，敏感指令自动陷入 Hypervisor。它让全虚拟化重新成为主流，也是 Xen 中 HVM 模式的基础。
- 操作系统级虚拟化：如容器，共享同一内核，隔离粒度较粗，不属于 Xen 这类 Type-1 Hypervisor 的讨论范围。
需要强调的是，PV 与 HVM 并非“新旧替代”关系，而是两种不同的协作契约。Xen 同时支持两者，并允许 PV on HVM、PVH 等混合形态，这正是 Xen 架构灵活性的体现。
二、Hypervisor 原理：位于硬件与 Guest 之间的特权层
Hypervisor（又称 VMM）是运行在最高特权级的软件层，核心职责包括：CPU 调度与虚拟化、内存虚拟化与隔离、设备与中断的虚拟化、以及虚拟机生命周期管理。它必须保证三件事：
- 隔离性：一个 Domain 的崩溃或越权不能影响其他 Domain。
- 可控性：所有敏感操作必须经过 Hypervisor 检查。
- 高效性：非敏感路径尽量让 Guest 直接执行，减少陷入开销。
Xen 属于 Type-1（裸金属）Hypervisor，直接运行在硬件之上，自身就是最底层的特权软件。它不依赖宿主操作系统，而是通过一个特殊的特权虚拟机来管理硬件，这一点与 KVM 依赖 Linux 内核作为 Hypervisor 的 Type-2 风格形成鲜明对比。
关键认知：Xen Hypervisor 本身非常精简，它只负责 CPU、内存和中断等核心虚拟化，并不包含完整的设备驱动。真正的设备驱动大多运行在 Domain 0 中，这也是 Xen 设备直通必须从 Domain 0 入手的原因。
三、Xen 架构：Hypervisor、Domain 0 与 Domain U 的分层
Xen 的经典架构可以概括为三层：最底层是硬件；中间是 Xen Hypervisor；上层是若干虚拟机，其中第一个启动的特权虚拟机称为 Domain 0（dom0），其余称为 Domain U（domU）。下图展示了这一分层关系与典型的数据/控制路径。
从图中可以看到，Domain 0 是 Xen 架构中的“管理中枢”。它拥有真实的设备驱动，负责与硬件直接交互；Domain U 则通过前端驱动与 Domain 0 的后端驱动通信，或通过直通方式直接访问被分配的物理设备。Hypervisor 位于两者之下，负责隔离与调度，但不直接参与大多数设备 I/O 的细节。
四、Domain 0 与 Domain U：角色、权限与协作
Domain 0 与 Domain U 的差异，不只是“先启动”与“后启动”，而是权限模型上的根本区别。下表对两者进行对比：
| 对比维度 | Domain 0（dom0） | Domain U（domU） |
|---|---|---|
| 特权级别 | 特权域，可访问 Xen 管理接口 | 非特权域，受 Hypervisor 约束 |
| 设备驱动 | 原生驱动，直接管理物理设备 | 前端驱动或直通后的原生驱动 |
| 管理职责 | 创建、配置、迁移、销毁 domU | 仅管理自身内部进程与服务 |
| 典型工具 | xl、xenstored、qemu-dm（HVM） | 无管理工具，仅 Guest OS 内部命令 |
| 直通角色 | 解绑设备、隐藏设备、分配 PCI ID | 加载驱动，直接使用直通设备 |
在设备直通场景中，Domain 0 的作用尤为关键。以 PCI 直通为例，通常需要先在 dom0 中确认设备状态，再将其从原生驱动解绑并分配给目标 domU：
# 在 Domain 0 中查看 PCI 设备
lspci -nn | grep -i ethernet
# 查看设备当前驱动绑定
ls -l /sys/bus/pci/devices/0000:03:00.0/driver
# 解绑原生驱动（示例）
echo 0000:03:00.0 > /sys/bus/pci/devices/0000:03:00.0/driver/unbind
# 在 domU 配置中声明直通设备
# xl create 时通过 pci = ['03:00.0'] 分配
这段流程说明：直通不是 Hypervisor 单独完成的事情，而是 Domain 0 与 Hypervisor、Domain U 三方协作的结果。Domain 0 负责“交出设备”，Hypervisor 负责“隔离与映射”，Domain U 负责“接管并使用”。
五、PV 与 HVM 模式对比：两种协作契约
PV 与 HVM 是 Xen 中两种最基础的 Guest 模式。PV Guest 使用修改过的内核，通过 hypercall 直接与 Hypervisor 交互，I/O 走前端/后端驱动；HVM Guest 使用未修改的操作系统，依赖硬件辅助虚拟化，I/O 通常由 QEMU 模拟，也可配合 PV 驱动提升性能。对比如下：
| 对比项 | PV 模式 | HVM 模式 |
|---|---|---|
| Guest 内核 | 需修改，感知 Xen | 无需修改，标准 OS 镜像 |
| CPU 虚拟化 | hypercall + 特权指令替换 | Intel VT-x / AMD-V 硬件辅助 |
| I/O 路径 | 前端/后端驱动，共享环 | QEMU 模拟，可加 PV 驱动 |
| 性能特点 | I/O 开销低，CPU 路径短 | 兼容性好，模拟 I/O 开销较高 |
| 典型场景 | 追求性能的服务器负载 | 需要运行 Windows 或未改内核 |
| 直通支持 | 支持，但受限于 PV 设备模型 | 支持完善，常用于 GPU / NIC 直通 |
实践提示：现代 Xen 部署中，HVM + PV 驱动（PV on HVM）是常见组合，它兼顾了 HVM 的兼容性与 PV 驱动的 I/O 性能。进行设备直通时，HVM 模式通常更直接，因为 Guest 可以像在物理机上一样加载原生驱动。
六、常见误区与复盘
- 误区一：把 Domain 0 当成普通虚拟机。dom0 是特权域，它崩溃往往意味着整个 Xen 主机管理面失效，因此生产环境中应避免在 dom0 中运行业务负载。
- 误区二：认为 Hypervisor 负责所有设备驱动。Xen Hypervisor 本身不含完整驱动，设备管理主要落在 dom0，这也是直通配置必须从 dom0 开始的原因。
- 误区三：把 PV 与 HVM 简单理解为“性能高低”。两者是不同协作模型，选择取决于 Guest OS 是否可修改、是否需要硬件辅助以及 I/O 路径要求。
- 误区四：忽略 IOMMU 与中断重映射。没有 IOMMU，直通设备无法安全地进行 DMA 隔离；没有中断重映射，直通设备的中断可能无法正确注入 domU。
复盘要点：在排查直通失败时，建议按“dom0 是否识别设备 → 驱动是否成功解绑 → Hypervisor 是否启用 IOMMU → domU 配置是否正确 → Guest 内驱动是否加载”的顺序逐层检查。这条链路正好对应本节所讲的 Xen 分层架构与 Domain 角色分工。
掌握虚拟化类型、Hypervisor 原理、Xen 三层架构、Domain 0 与 Domain U 的权限差异，以及 PV 与 HVM 的协作契约，是后续理解设备直通与资源隔离的必备基础。只有先看清“谁在什么位置、拥有什么权限、通过什么路径访问硬件”，才能在工程实践中准确判断问题出在哪一层。