Returning 0 will satifsy OpenBSD guests that this feature is disabled and allow running xhyve without -w.
This might also need to be upstreamed to bhyve, as I found a similar report for it (and workaround with -w): https://marc.info/?t=149136054700003&r=1&w=2
A reply to that thread indicated the hardenedbsd fork fixed it via returning a "locked and disabled" value in that MSR, but that doesn't seem to have made it into FreeBSD bhyve. Also, in my testing simply returning 0 (disabled) is sufficient.
This only affects certain host CPUs (those with the SDBG CPU ID bit, which bhyve/xhyve pass through), but they're apparently common among recent-ish Macs. An alternative solution would be to mask off that CPU ID bit, but this seemed like a simpler solution.
OpenBSD since 6.1 reads this register and attempts to disable the debug interface if enabled. Ref: https://github.com/openbsd/src/commit/61bf105
Returning 0 will satifsy OpenBSD guests that this feature is disabled and allow running xhyve without
-w.This might also need to be upstreamed to bhyve, as I found a similar report for it (and workaround with
-w): https://marc.info/?t=149136054700003&r=1&w=2A reply to that thread indicated the hardenedbsd fork fixed it via returning a "locked and disabled" value in that MSR, but that doesn't seem to have made it into FreeBSD bhyve. Also, in my testing simply returning 0 (disabled) is sufficient.
This only affects certain host CPUs (those with the SDBG CPU ID bit, which bhyve/xhyve pass through), but they're apparently common among recent-ish Macs. An alternative solution would be to mask off that CPU ID bit, but this seemed like a simpler solution.