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

[liweitianux]

Issue #3452 has been updated by liweitianux.

Assignee set to liweitianux

> DragonFly ships the older NVMM user API, which has no @nvmm_vcpu_stop at .

The NetBSD's implementation of @nvmm_vcpu_stop@ is bogus, so we didn't port that over.

I implemented a better version based on the author's design, but I didn't finish testing it. Anyway, we'll implement that API and update the Qemu support.

* "nvmm(4): Implement the kernel support for nvmm_vcpu_stop() API":https://github.com/liweitianux/dragonflybsd/commit/96f08e13a7fbe815ecbc422627bd10e827667ac7
* "libnvmm(3): Implement nvmm_vcpu_stop() API":https://github.com/liweitianux/dragonflybsd/commit/fbdeb3d0217c362e266e1eb325115ee724a82d22

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

* 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 .



-- 
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