GICv3 加 MTTCG 的 loadvm 停滞

【踩坑实录】GICv3 加 MTTCG 的 loadvm 停滞

▍现象
虚拟机工程做快照恢复（loadvm）测试：GICv3 中断控制器配置加 MTTCG 多线程翻译的组合下，恢复指令发出后虚拟机停滞——CPU 不推进、界面无响应，无任何错误输出。换 GICv2 配置同流程正常。

▍定位过程
最初怀疑快照文件损坏，重新保存多份仍然停滞；又怀疑存储 IO，监控读写正常。真正破局的是组合矩阵测试：中断控制器版本与单多线程交叉四组跑，结论收敛——GICv3 加 MTTCG 这一组停滞，GICv3 单线程、GICv2 单线程、GICv2 多线程都正常。这是同类虚拟机工程早期实测过的结论：GICv3 中断控制器与 MTTCG 组合下 loadvm 恢复停滞，GICv2 加多线程正常。

▍根因
GICv3 的中断状态机在多线程翻译的恢复路径上存在兼容缺陷：恢复时刻各虚拟 CPU 的中断控制器状态分发与 MTTCG 的线程唤醒次序耦合出错，恢复流程卡在中断注入的等待上。属于模拟器层的组合性边界问题，不是应用侧配置错误。

▍对策
选型约束直接写进工程基线：需要快照恢复的虚拟机一律 GICv2 加多线程组合；四机矩阵测试把 GICv2 路线列为重点覆盖项；GICv3 路线仅用于不需要快照的场景。这条约束后来在虚拟机工程的快照产品化（极速启动通道）中持续生效——快照通道的全部价值建立在 loadvm 可靠之上。

▍方法论沉淀
组合类问题的定位利器是单变量矩阵：把可疑因素（这里是控制器版本与线程模式）全组合跑一遍，问题只落在一格，根因自明。比逐个猜快一个数量级。这条经验来自 Air 系列虚拟机工程的真实记录，完整过程见适配全记录对应篇目。

有类似组合性卡死的案例，欢迎到 apps 板块对照 56 篇适配全记录实录一起讨论。