aboutsummaryrefslogtreecommitdiff
path: root/contrib/ntp/ntpd/refclock_atom.c
diff options
context:
space:
mode:
authorMark Johnston <markj@FreeBSD.org>2025-09-10 16:00:36 +0000
committerMark Johnston <markj@FreeBSD.org>2025-09-10 16:00:36 +0000
commit3d39856d4dfeab5b5a5e6bbdb6ce965db5bc4dc1 (patch)
tree6ca7aaa4fcb829af7bf416dd15223cad9e47649a /contrib/ntp/ntpd/refclock_atom.c
parentb653a281f5a977ba73b3d405874f8af8e8b6b50d (diff)
vmm: Suspend the VM before destroying itHEADmain
Otherwise we don't do anything to kick vcpu threads out of a sleep state when destroying a VM. For instance, suppose a guest executes hlt on amd64 or wfi on arm64 with interrupts disabled. Then, bhyvectl --destroy will hang until the vcpu thread somehow comes out of vm_handle_hlt()/vm_handle_wfi() since destroy_dev() is waiting for vCPU threads to drain. Note that on amd64, if hw.vmm.halt_detection is set to 1 (the default), the guest will automatically exit in this case since it's treated as a shutdown. But, the above should not hang if halt_detection is set to 0. Here, vm_suspend() wakes up vcpu threads, and a subsequent attempt to run the vCPU will result in an error which gets propagated to userspace, allowing destroy_dev() to proceed. Add a new suspend code for this purpose. Modify bhyve to exit with status 4 ("exited due to an error") when it's received, since that's what'll happen generally when the VM is destroyed asynchronously. Reported by: def MFC after: 2 weeks Sponsored by: Innovate UK Differential Revision: https://reviews.freebsd.org/D51761
Diffstat (limited to 'contrib/ntp/ntpd/refclock_atom.c')
0 files changed, 0 insertions, 0 deletions