ovmm/ohcl: stop state units before worker teardown

[Steven Malis (smalis-msft)]

The OpenVMM and OpenHCL VM workers could leave their event loops and begin partition teardown while state units were still running.

Partition teardown stops and joins the VPs, but it does not quiesce storage, networking, integration components, VMBus channels, or other device units. Dropping state-unit request channels is also not equivalent to calling StateUnit::stop(): unit shutdown then proceeds asynchronously and can race destruction of resources used by those units.

This invalid ordering presumably appeared in https://openvmm.dev/test-results/#/runs/33535442457_1/x64-linux-amd-kvm-vmm-tests-logs/multiarch__ic__openvmm_uefi_x64_windows_datacenter_core_2022_x64_kvp_ic. The guest powered off cleanly, but no final state-unit stop transition occurred before RAM invalidation, after which the OpenVMM child exited with SIGABRT. The artifact does not identify the exact faulting task, but the missing teardown barrier is a correctness issue independently of that attribution.

OpenHCL had the same structural gap: normal worker stop or worker-channel closure proceeded directly to partition, VMBus relay, and VMBus server teardown. Its restart and servicing paths already stopped state units first.

This is less likely to cause the same crash in OpenHCL. Its lower-VTL memory mappings are reference-counted through the GuestMemory views held by devices, and the VM worker runs in a dedicated subprocess that exits after teardown. Unlike the OpenVMM path, dropping the top-level memory owner therefore does not immediately invalidate mappings still referenced by devices.

Nevertheless, skipping StateUnit::stop() bypasses explicit, awaited cleanup for the partition, VMBus relay, offered channels, and other devices. Adding the same barrier makes the lifecycle ordering correct and consistent, even though the failure is less acute and has not been observed in OpenHCL.

To fix this, we simply stop state units at the common teardown boundary in both workers:

• OpenVMM calls LoadedVm::pause() before partition teardown.
• OpenHCL calls LoadedVm::stop() before partition teardown.

Both helpers are conditional: if the VM is already stopped, they do nothing. Otherwise, they stop all state units in reverse dependency order and wait for their stop operations to complete.

Placing the calls after the worker event loops covers explicit worker shutdown as well as worker or RPC channel closure paths. Restart and servicing paths that already stopped the VM are unaffected.

[Copilot]

🟢 Approval recommended

The change uses existing, idempotent stop/pause helpers to enforce correct teardown ordering without introducing new control flow or error-handling risks.

Pull request overview

This PR fixes VM teardown ordering in both OpenVMM and OpenHCL workers by ensuring state units are explicitly stopped (and awaited) before partition teardown begins, preventing state-unit shutdown from racing destruction of underlying resources.

Changes:

• OpenVMM: call LoadedVm::pause() on the common teardown boundary before partition_unit.teardown().
• OpenHCL: call LoadedVm::stop() on the common teardown boundary before partition_unit.teardown().
• Aligns worker shutdown and channel-closure paths with the already-correct restart/servicing paths that stop state units first.

File summaries

File	Description
openvmm/openvmm_core/src/worker/dispatch.rs	Adds a pause().await barrier before partition teardown to stop state units deterministically.
openhcl/underhill_core/src/dispatch/mod.rs	Adds a stop().await barrier before partition teardown to stop state units deterministically.

Review details

• Files reviewed: 2/2 changed files
• Comments generated: 0
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[github-actions]

1 Petri tests failed (0 unstable)