虚拟化 uxn
内容提要
文章探讨如何让 uxn 虚拟机支持虚拟化。作者依据 Popek 和 Goldberg 理论分析，指出 uxn 虽无特权指令和模式切换，但可通过递归虚拟化实现。为此提出为每个虚拟机增加基址、界限寄存器及陷阱机制，并扩展系统设备指令，用 Uxntal 编写了简易 hypervisor“xun”，成功运行程序。差异在于设备使用虚拟地址时需复制媒体数据。未来可支持 32 位地址、抢占式多任务及类 System-7 系统。
延伸解读
uxn 虚拟化的理论依据
文章依据 Popek 和 Goldberg 的虚拟化理论分析 uxn：由于 uxn 没有特权指令和模式切换，所有控制敏感与行为敏感指令集合为空，因此构建虚拟机监控器（VMM）在理论上是可行的。作者进一步指出，uxn 执行是确定性的，根据该理论的定理 2，uxn 可以递归虚拟化。这为在 uxntal 中实现 hypervisor 提供了理论基础。
实现虚拟化的关键机制
作者为每个虚拟机增加了 32 位基址和界限寄存器，所有内存访问（包括取指令）都受其约束，越界会触发内存故障。设备指令 DEI/DEO 不再直接调用处理程序，而是陷入父虚拟机代为执行。系统设备扩展了 getBound 和 vmExec 操作，配合虚拟机控制块（VMCB）完成上下文切换。这些改动足以用 Uxntal 编写简易 hypervisor“xun”。
虚拟化带来的行为差异
由于设备使用虚拟地址而非物理地址，hypervisor 需要先复制精灵、音频样本等媒体数据。这导致可观察的行为差异：直接运行 piano.rom 时，弹奏音符后修改波形会实时改变音色；而在 xun 下，修改要等到下一次弹奏才生效。作者建议将设备内存中的地址改为 32 位物理地址，以消除复制并允许 ROM 使用低 64k 以外的媒体。
当前局限与后续方向
xun 目前硬编码加载特定 ROM，尚不能递归运行自身，也未处理设备多路复用。作者计划让设备支持 32 位地址、完善自描述设备以便嵌套虚拟机发现 hypervisor 提供的功能，并考虑加入“燃料计数器”实现抢占式多任务。最终目标是构建类似 System-7 的系统，用虚拟化 uxn 运行程序。
Q&A
uxn 虚拟机本身支持虚拟化吗？
uxn 目前是“实模式”机器，没有对运行虚拟 uxn 机器的 hypervisor 提供支持。但根据 Popek 和 Goldberg 理论分析，uxn 没有特权指令和模式切换，因此可以通过递归虚拟化实现虚拟化。
为什么 uxn 可以被虚拟化？
因为 uxn 没有特权指令、没有控制敏感指令，也没有行为敏感指令（在考虑地址转换后），所有敏感指令集合为空，满足 Popek 和 Goldberg 定理 1，所以构建 VMM 是可行的。此外，uxn 执行是确定性的，因此也可递归虚拟化。
实现 uxn 虚拟化需要增加哪些机制？
需要为每个虚拟机增加 32 位基址和界限寄存器，以及陷阱机制；扩展系统设备指令（如 getBound 和 vmExec）；修改 BRK、DEI、DEO 指令的行为，使其触发陷阱而非直接执行；并处理内存和栈故障。
xun 是什么？它目前能做什么？
xun 是用 Uxntal 编写的简易 hypervisor，目前硬编码加载特定 ROM（bin/xuninner.rom），不能递归运行自身，也缺乏设备多路复用，但已能成功运行程序（如 piano.rom），展示了基本虚拟化功能。
虚拟化执行与直接执行在设备行为上有什么差异？
由于设备使用虚拟地址，hypervisor 需要先复制媒体数据（如精灵、音频样本）再让硬件使用。例如运行 piano.rom 时，直接执行下修改波形会立即改变音色，而虚拟化下音色保持不变，直到下次播放音符才生效。
uxn 虚拟化未来有哪些改进方向？
未来可支持 32 位地址（便于设备直接使用翻译后的地址，避免复制），完善 xun 以支持完全递归虚拟化，增强设备自描述支持，并可能加入“燃料计数器”实现抢占式多任务，最终构建类似 System-7 的系统。
