Spark Notes

Appearance

虚拟机调试增强 ​

虚拟机在调试场景下有一个真实硬件无法比拟的优势：虚拟机监视器（Hypervisor）能看到虚拟机的全部状态。物理内存的每个字节、CPU 读取的每个设备寄存器、执行的每条指令——对真实硬件而言这些信息需要复杂的调试硬件才能获取，对虚拟机而言只是监视器内部的数据结构。用好这些能力，内核调试的效率可以提升一个数量级。

QEMU Monitor：直接观察虚拟机内部 ​

QEMU Monitor 是 QEMU 提供的交互式控制台（-monitor stdio 重定向到终端），它运行在宿主机侧，可以检查虚拟机的任意内部状态。内核调试中最有用的两个命令：

xp（examine physical）直接读取虚拟机的物理内存。与 GDB 的 x 命令不同，xp 绕过了虚拟机的 MMU 转换——直接按物理地址读取。内核调试中页表损坏、MMU 初始化错误这些场景，虚拟地址访问已经不可靠，只有物理内存视图还能看到真实状态：

(qemu) xp /20x 0x100000       # 查看物理地址 0x100000 起的 20 个字
(qemu) xp /s 0xffff800000000000  # 以字符串形式查看

info registers 查看虚拟 CPU 的寄存器状态，info tlb 查看 TLB 条目（验证 MMU 是否按预期工作），info mtree 查看内存映射树（验证设备 BAR 是否映射到预期地址）。对于"内核初始化内存后行为异常"这类问题，xp + info mtree 的组合往往比 GDB 断点更快定位——先确认物理内存的内容对不对，再确认地址映射对不对，问题就缩小了一半。

设备寄存器访问监控 ​

"CPU 读取了哪些设备的寄存器"是驱动调试的核心问题。真实硬件上这需要逻辑分析仪挂在总线上，QEMU 中只需要打开跟踪。

-d guest_errors 是 QEMU 最常用的调试开关——它记录虚拟机访问了未实现或未映射的 MMIO/PIO 地址：

bash
qemu-system-x86_64 -kernel bzImage -initrd initramfs.cpio.gz \
  -append "console=ttyS0 nokaslr" \
  -d guest_errors -D guest.log

启动后查看 guest.log，每行记录了非法访问的地址、方向和大小。驱动开发中遇到"读写寄存器没反应"的问题，第一步就是看 guest_errors——如果日志里出现你的设备 BAR 范围内的访问记录，说明驱动访问的地址和设备模拟的地址不匹配。

更细粒度的跟踪通过 trace-events 实现。QEMU 内置了数百个跟踪点，覆盖设备模型的每个寄存器读写：

bash
# 列出设备相关的跟踪点
qemu-system-x86_64 -trace help | grep e1000

# 启用跟踪并输出到文件
qemu-system-x86_64 -kernel bzImage \
  -trace events=/path/to/trace-events -D trace.log

trace-events 文件格式简单：一行一个 事件名 参数 模式，支持通配符。设备驱动的寄存器读写序列可以被完整记录下来，与驱动代码逐行对照——这正是"观察 CPU 和设备之间的对话"。

与 GDB 的配合 ​

QEMU Monitor 和 GDB 可以同时使用——GDB 用于指令级调试（断点、单步、调用栈），Monitor 用于状态级观察（内存、寄存器、设备）。两者的分工是：GDB 回答"代码执行到了哪里、变量值是什么"，Monitor 回答"虚拟机整体的物理状态是什么"。

一个典型的调试会话：GDB 断点在驱动初始化函数 → 单步执行寄存器读写 → 同时用 -d guest_errors 日志对照每次访问的地址 → 发现地址偏移错误 → 用 xp 确认实际写入的内存内容。三个工具提供三个不同层次的视图，交叉验证结论。

对虚拟化开发本身（写 hypervisor、调试 VMM），QEMU 还支持嵌套虚拟化（-enable-kvm 配合 -cpu host），在虚拟机内再跑虚拟机——内层虚拟机的调试同样可以使用上述全部手段。云厂商的虚拟化团队大量依赖这种"QEMU 调试 QEMU"的工作流。

增强方向 ​

"实时显示物理内存值"和"监控寄存器访问"这两件事，QEMU 原生能力已经覆盖了大半。进一步的增强方向：

物理内存的实时监视可以通过 GDB 的 hardware watchpoint 实现——QEMU 将 GDB 的 watch 命令翻译为对虚拟内存的写监控，rwatch 监控读访问。配合 xp 的物理地址视图，可以精确到"哪个物理地址何时被谁读写"。

设备寄存器访问的结构化分析工具（如 qemu-trace-stap 的 SystemTap 集成）可以将寄存器读写与虚拟机的控制流关联起来——不只是知道"地址 0x4000 被读取了"，而是知道"是哪个线程、在哪个函数中读取了 0x4000"。这对于多线程驱动中的竞态调试价值极大。

内核调试的终极形态是确定性重放（Deterministic Replay）——QEMU 的 rr 模式记录虚拟机的全部非确定性输入（中断时机、DMA 时序），支持反复重放同一次执行。竞态 bug 的一次性崩溃现场可以被无限次重放、逐指令分析。这个能力目前在 QEMU 中处于实验阶段（icount 模式），但方向已经明确：虚拟机的可调试性上限远未触及。