QEMU为何使用JIT编译？TCG虚拟化相关技术问题咨询

你提到的将操作系统编译为高效通用中间表示（IR）、完全通过软件虚拟机运行的方案，在现实中是完全可行的，且已经有大量成熟的实践案例，其核心逻辑和QEMU TCG的翻译思路同源，只是把指令翻译的环节从运行时提前到了OS编译阶段。

核心逻辑和现有实践 #

QEMU TCG的工作流是「客户机原生指令 → TCG中间IR → 宿主机原生指令」，你提出的方案相当于跳过了第一步的动态翻译过程，直接将OS源码编译为统一IR，运行时只需要将IR翻译为宿主机指令即可，省去了客户机指令解析的开销，实际表现通常比TCG全虚拟化的性能更高：

• 微软早年推出的Singularity实验性操作系统，整体就是编译为.NET平台的MSIL字节码运行，所有系统隔离、权限校验都通过字节码验证完成，不需要依赖硬件内存保护单元，已经实现了可稳定运行的完整原型。
• 当下云原生场景大量使用的Unikernel（比如IncludeOS）已经支持直接编译为WebAssembly（WASM）IR，可在Wasmtime、WAVM等通用WASM虚拟机上直接运行，同等配置下性能比-accel=tcg模式启动的同架构Linux虚拟机高40%以上。
• 不少嵌入式场景也已经采用类似方案，将实时操作系统编译为自定义的精简IR，同一固件镜像可以直接在X86、ARM、RISC-V等不同架构的设备上运行，大幅降低了多架构适配的维护成本。

现实落地的优势 #

• 可移植性极强：只要目标硬件平台有对应IR的虚拟机实现，整个OS不需要做任何修改即可运行，相比QEMU TCG需要模拟全架构的特权指令、外设寄存器，方案复杂度低得多。
• 优化空间充足：固定IR的虚拟机可以针对性做深度JIT、AOT编译优化，性能可以接近原生编译的操作系统，远高于TCG动态翻译的性能上限。
• 安全特性更灵活：可以在IR层统一实现内存安全校验、控制流完整性防护等能力，无需依赖硬件特性即可消灭缓冲区溢出、UAF等大量内核常见漏洞。

目前的局限性 #

• 生态适配成本高：现有绝大多数操作系统、上层应用软件都是针对X86、ARM等原生指令集开发，全量重新编译到通用IR的工作量极大，闭源软件无源码的情况下更是无法完成适配。
• 特权语义适配复杂：通用IR大多最初是为用户态程序设计，要支持操作系统所需的中断处理、内存管理、外设访问等特权操作，需要对IR和虚拟机做大量定制扩展，开发成本较高。
• 极致性能场景仍有差距：为了保证可移植性保留的抽象层开销，使得这类方案在对延迟、吞吐量要求极高的核心场景，仍然比不上针对特定硬件架构深度优化的原生操作系统。

内容的提问来源于stack exchange，提问作者emandret