|Priority:||4 - Normal|
|Created by:||Hans Rosenfeld [X]|
|Reported by:||Hans Rosenfeld [X]|
|Assigned to:||Hans Rosenfeld [X]|
Fixed: A fix for this issue is checked into the tree and tested.
(Resolution Date: 2019-02-13T23:33:38.558Z)
2019-02-14 Liz Lemon (Release Date: 2019-02-14)
There's an edge case in the mdb bhyve target where it may attach to a VM that is still in the process of being created by the bhyve userspace process. As soon as the VM is created in the kernel mdb may attach, and if it does so before the first vCPU is set up it will end up in an odd state with no valid CPU to single-step or to use for address translation.
To avoid this libvmm should check the CPU count on VM open, waiting and retrying until it gets a non-zero count.
I tested this by starting a VM repeatedly, each time starting mdb immediately after. Previously that would be enough to get mdb into a weird state with no usable vCPUs. Now mdb waits for the first vCPU to be configured and is fully usable afterwards.
illumos-joyent commit 2d1a8a4a97fe44c06e3fedddbb32f89fc2755a3e (branch master, by Hans Rosenfeld)
OS-7508 mdb: assertion tripped in libvmm when bhyve VM halts while mdb is attached
OS-7519 mdb: bhyve target can attach before the first vCPU is configured