[DragonFlyBSD - Bug #3452] nvmm: trap CR0.PE changes so guest mode switches reconfigure the VMCS

sigttou bugtracker-admin at leaf.dragonflybsd.org
Sun Oct 18 20:34:09 PDT 2026


Issue #3452 has been updated by sigttou.

File 0001-nvmm-4-Add-CR0_NE-to-the-CR0-guest-host-mask.patch added

Corrected cause and a smaller fix. This replaces my earlier explanation that the hang came from QEMU's INIT/SIPI delivery and the missing nvmm_vcpu_stop(): tracing showed INIT/SIPI delivered promptly and in order, and the AP entering its trampoline every time, so that explanation was wrong.

CR0_NE is fixed to 1 in VMX operation (IA32_VMX_CR0_FIXED0) but is not in CR0_STATIC_MASK (ET|NW|CD), so it is guest-owned. GNU Mach's AP trampoline writes CR0=0x60000011 (PE set, NE cleared). That raises #GP(0) and leaves CR0 unchanged. The fault goes through the guest's real-mode IVT to the BIOS handler, which returns to the same instruction, and the AP spins. The CR0.PE trap from my first patch only hid this, because that exit reaches the CR0 handler, which forces NE to 1.

Proposed fix: add CR0_NE to CR0_STATIC_MASK. The guest then reads NE from the read shadow, the trampoline's write does not exit, CR0 keeps NE=1 and PE is loaded normally. 

Tested: 32-bit and 64-bit GNU Mach guests hang without it and boot with it (-smp 2 and -smp 4). DragonFly and Debian 13 x86_64 guests still boot with all CPUs.

-- 

This is WIP.

----------------------------------------
Bug #3452: nvmm: trap CR0.PE changes so guest mode switches reconfigure the VMCS
http://bugs.dragonflybsd.org/issues/3452#change-14859

* Author: sigttou
* Status: In Progress
* Priority: Normal
* Assignee: liweitianux
* Category: nvmm
* Target version: 6.6
* Start date: 2026-10-16
----------------------------------------
QEMU's NVMM glue only checks for pending INIT/SIPI at the start of its outer run loop. DragonFly ships the older NVMM user API, which has no @nvmm_vcpu_stop at . So QEMU can't kick a vCPU out of its inner loop, and the AP's start-up signals arrive late and merged. The AP ends up looping in the BIOS while the BSP waits forever.


NetBSD NVMM likely doesn't have this issue because of @vcpu_stop at .

---Files--------------------------------
0001-nvmm-4-Add-CR0_NE-to-the-CR0-guest-host-mask.patch (1.9 KB)


-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account


More information about the Bugs mailing list