savevm 的 pflash 写回修复

【踩坑实录】savevm 的 pflash 写回修复

▍现象
虚拟机工程做快照保存（savevm）：保存到中途失败或保存出的档恢复后固件行为异常（启动变量丢失、引导流程错乱）。快照链路的其他部分（内存、磁盘）都正常，唯独固件状态不可靠。

▍定位过程
快照的内容物逐项排查：客户机内存镜像正常、磁盘状态正常、设备状态正常，问题锁定在固件单元。该工程的固件是 edk2 双单元结构：代码单元只读、变量单元可写（系统设置的持久化靠它）。检查保存流程发现：变量单元的写回没有被正确纳入快照时序——保存时刻的固件变量状态与快照点不一致，恢复出来就是错位的固件状态。工程记录里这次修复有明确编号：修好 pflash 单元写回后，保存实测约两点零吉字节耗时约三分钟，通道从此稳定。

▍根因
固件的双单元语义特殊：一读一写，写单元的状态必须在快照时刻原子纳入（写回时机、写回完整性两个条件）。模拟器的默认快照流程对这种自定义双单元结构的覆盖不完整，需要工程侧显式处理写回。

▍对策
修复写回时序（保存流程里显式触发固件变量单元的落盘并纳入一致性点）；快照后校验（恢复冒烟：固件变量读取核对）；快照标签语义化（工程给快照档起语义名标记成熟度——成熟档才进极速启动通道，实验档隔离）。配套的空间纪律：保存成功后自动回收旧档（工程实测自动回收链把空间占用压住——快照一两个吉字节，回收机制不可少）。

▍方法论沉淀
快照的完整性是全对象的概念：内存、磁盘、设备、固件变量，一个都不能少——缺一个就是恢复后诡异故障（最难排查的那类，因为一切看起来都正常）。

虚拟机工程快照产品化的全过程在适配全记录，apps 板块 56 篇实录欢迎对照。