Page MenuHomeFreeBSD

vmm: Suspend the VM before destroying it
ClosedPublic

Authored by markj on Aug 6 2025, 3:09 PM.
Tags
None
Referenced Files
Unknown Object (File)
Fri, Oct 10, 1:04 AM
Unknown Object (File)
Fri, Oct 10, 1:04 AM
Unknown Object (File)
Fri, Oct 10, 1:04 AM
Unknown Object (File)
Thu, Oct 9, 8:49 PM
Unknown Object (File)
Sun, Sep 28, 6:12 AM
Unknown Object (File)
Wed, Sep 24, 1:16 AM
Unknown Object (File)
Sep 20 2025, 5:12 PM
Unknown Object (File)
Sep 20 2025, 3:26 PM

Details

Summary

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

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

markj requested review of this revision.Aug 6 2025, 3:09 PM

I'd like to commit this soon if there are no objections.

This revision was not accepted when it landed; it landed in state Needs Review.Sep 10 2025, 4:01 PM
This revision was automatically updated to reflect the committed changes.