📚 课程目录第3章 Xen设备模型

3. Xen设备模型

在 Xen 架构中，虚拟机对设备的访问并不是简单地“把物理设备塞进 guest”，而是由一整套设备模型协同完成。理解这套模型，是后续做设备直通、资源隔离和性能调优的基础。Xen 的设备模型可以概括为三条路径：全模拟路径（QEMU 设备模拟）、半虚拟化路径（PV 前端/后端驱动）、以及直通路径（PCI Passthrough，后续章节展开）。本节聚焦前两条路径及其支撑机制：XenStore、XenBus、事件通道和授权表。

一、QEMU 设备模拟：兼容性优先的“影子设备”

对于 HVM（硬件虚拟机）客户机，Xen 借助 QEMU 提供设备模拟。Guest 看到的是一块“真实”的网卡、磁盘控制器或显卡，例如 Intel E1000 网卡、IDE/SATA 控制器、VGA 设备。Guest 内部的原生驱动直接操作这些模拟寄存器，QEMU 捕获 I/O 端口、MMIO 访问并模拟设备行为。

这种方式的优点是兼容性极强：任何操作系统自带的驱动都能工作，无需修改 guest 内核。缺点是性能开销大：每次寄存器访问都要触发 VM Exit，陷入 Xen，再转发给 QEMU 处理，路径长、延迟高。因此 QEMU 模拟通常用于启动阶段、兼容性兜底，或对性能不敏感的慢速设备。

在 xl 配置中，device_model_version="qemu-xen" 指定使用 QEMU 作为设备模型；device_model_override 可指定具体 QEMU 二进制路径。

二、PV 前端/后端驱动：拆分式设备模型

半虚拟化设备（PV Device）把设备驱动拆成两半：运行在 Guest 内的前端驱动（Frontend），和运行在 Driver Domain（通常是 Dom0）内的后端驱动（Backend）。前端不直接碰硬件，而是把 I/O 请求写入共享内存环（Ring），后端从环中取出请求、操作真实硬件，再把结果写回环中。

以 virtio-net 或 Xen netfront/netback 为例，典型流程如下：

Guest 前端把网络包描述符写入 TX Ring，更新生产者指针。
前端通过事件通道通知后端“有新请求”。
后端从 Ring 读取描述符，通过授权表映射 guest 内存页，拷贝或直接读取数据。
后端把数据发送到物理网卡，完成后把响应写回 RX Ring。
后端通过事件通道通知前端“请求已完成”。

这条路径避免了大量 VM Exit，数据通过共享内存传递，性能远高于纯模拟，同时保持较好的隔离性——后端崩溃通常只影响对应 guest 的设备服务。

三、XenStore、XenBus、事件通道与授权表：四大支撑机制

PV 设备模型能运转，依赖四个关键机制，它们各司其职又紧密配合：

机制	作用	典型内容
XenStore	域间共享的键值配置数据库	设备路径、后端 ID、状态、ring-ref、event-channel 端口号
XenBus	基于 XenStore 的设备发现与状态机	State 从 Initialising → Connected → Closing
事件通道	轻量级异步通知机制	前端/后端互相唤醒，替代轮询
授权表	受控的跨域内存共享	后端映射前端 Ring 与数据页，grant ref 授权

XenStore 是一个由 Xenstored 维护的树状键值库。每个设备在 /local/domain/<domid>/device/<type>/<devid> 下有对应节点，后端信息在 /local/domain/<backend-domid>/backend/<type>/<domid>/<devid>。前端通过读取这些路径获知后端位置、ring 引用和事件通道端口。

XenBus 是建立在 XenStore 之上的设备状态机。设备连接过程本质上是双方在 XenStore 中写状态、互相观察状态变化的过程。常见状态包括：

XenbusStateInitialising = 1
XenbusStateInitWait     = 2
XenbusStateInitialised  = 3
XenbusStateConnected    = 4
XenbusStateClosing      = 5
XenbusStateClosed       = 6
XenbusStateReconfiguring= 7
XenbusStateReconfigured = 8

前端写 state=Initialising，后端观察到后准备资源并写 InitWait，前端再写 Initialised，双方最终进入 Connected，设备可用。任何一方异常都会把状态推向 Closing/Closed，触发清理。

事件通道（Event Channel） 是 Xen 提供的异步通知原语。每个前端/后端对会分配一对事件通道端口，一方通过 EVTCHNOP_send 触发另一方的中断处理。它不传输数据，只传递“有事发生”的信号，数据仍在共享 Ring 中。

授权表（Grant Table） 解决“跨域内存共享如何安全进行”的问题。前端把 Ring 页和数据页的 grant reference 写入 XenStore，后端用 GNTTABOP_map_grant_ref 把这些页映射进自己的地址空间。授权是显式、可撤销的，后端只能访问被授权的页，不能越界读取 guest 其他内存。

四、案例：一次 virtio-net 设备连接的全过程

假设在 Dom0 中通过 xl 启动一个带 PV 网卡的 DomU，配置片段如下：

vif = [ 'mac=00:16:3e:aa:bb:cc, bridge=xenbr0' ]

连接过程可拆解为：

Xen 工具栈在 XenStore 中创建前端节点 /local/domain/1/device/vif/0，写入 backend 路径、mac、state=1。
Dom0 的 netback 观察到新设备，创建后端节点，分配事件通道端口和 Ring 页，把 event-channel、tx-ring-ref、rx-ring-ref 写入后端节点。
前端读取这些参数，通过授权表把 Ring 页授权给后端，写 state=4（Connected）。
此后收发数据：前端写 TX Ring → 事件通道通知后端 → 后端映射授权页读取数据 → 发往物理网卡。

关键点：XenStore 负责“找到对方并交换参数”，事件通道负责“通知对方”，授权表负责“安全地共享内存”，XenBus 负责“双方状态对齐”。四者缺一不可。

五、常见误区与排障思路

误区一：把 XenStore 当数据通道。 XenStore 只适合小量配置和状态，不适合传大数据。大量数据必须走共享 Ring。
误区二：忽略授权表泄漏。 如果后端异常退出未撤销 grant，前端页可能长期被映射，造成内存无法释放。排障时可检查 /proc/xen/grant 或使用 xenstore-ls 观察残留节点。
误区三：事件通道端口冲突。 端口由 Xen 统一分配，但手工配置或热插拔异常时可能残留。可用 xenstore-read 核对前后端记录的端口是否一致。
排障顺序建议： 先看 XenStore 中前后端 state 是否一致，再看事件通道端口是否匹配，最后检查授权表映射是否成功。

# 查看设备状态
xenstore-ls /local/domain/1/device/vif/0
xenstore-ls /local/domain/0/backend/vif/1/0

# 查看事件通道
xenstore-read /local/domain/1/device/vif/0/event-channel

# 查看授权表
cat /proc/xen/grant

掌握 QEMU 模拟、PV 前后端、XenStore、XenBus、事件通道和授权表这六个概念及其协作关系，就掌握了 Xen 设备模型的“骨架”。后续做设备直通时，你会看到直通路径如何绕过或复用这些机制，从而在性能与隔离之间做出取舍。