[Pedro Henrique Penna (ppenna)]

Pin OpenVMM 70dde4c65 from nanvix/openvmm#129, which preserves a partition's halt state across snapshots: a partition that halted before its snapshot now restores halted and reports its halt again, instead of restoring with runnable vCPUs and no halt report.

Problem

When the guest powers off, resets, or triple-faults, or a debugger stops it, OpenVMM's partition unit records the first HaltReason, latches every vCPU stopped, and reports the halt to the client or to an attached debugger. The partition's saved state had no field for that halt (// TODO: save halted state), and its restore left it out (// TODO: restore halted state). A snapshot of a halted partition therefore restored with runnable vCPUs and reported nothing, so the guest could run past a power-off that it had already requested.

Change

The openvmm gitlink moves from 2130f24b5 to 70dde4c65, one commit on nanvix/openvmm main at 2130f24b5, which dev already pins. In vmm_core's partition unit, it:

• saves the first halt reason, mesh-encoded, in a new optional field 3 of the partition.Partition saved state;
• refuses a restore over a halt that the partition recorded, or that a vCPU raised but the partition has not recorded yet, before it restores any state;
• otherwise restores the partition and vCPU state, latches the vCPU halt again, and reports the halt as the original halt did, so the VM controller applies its guest power action to it;
• adds unit tests for the saved field, the vCPU halt latch, and the save and restore of halted and running partition units.

A partition that is not halted saves no halt reason. mesh writes nothing for an absent optional field, so its saved state keeps the same bytes and existing snapshots restore as before, and a build without this change skips the unknown field and restores a halted snapshot unhalted, as it did. NVX microVM captures are requested by the running guest through PMIO 0x605, so a captured partition is halted only if a halt raced the capture.

The second commit records the new pin in doc/openvmm-upstream-roadmap.md as position 309, as #475 did for the previous pin.

Provenance

• vmm_core: preserve halt state across snapshots nanvix/openvmm#129, by Ruize Tang (@tangruize), was one commit, 320f31ff7, on 7bf0ee28b, three commits behind nanvix/openvmm main. Its SSH signature is cryptographically valid, but its key is not in my allowed signers, so the signer's identity is unverified.
• I rebased it onto main at 2130f24b5 without conflicts. git range-diff 7bf0ee28b..320f31ff7 2130f24b5..<rebased> reported the commit unchanged (=), and both versions have the stable patch ID e067c6fa9.
• I then folded the fixes for the pull request's three Copilot review findings into that commit, signed it, force-pushed fix/snapshot-halt-state with a lease on the reviewed head, and replied to and resolved each thread. The result, 70dde4c65, keeps Ruize Tang (@tangruize) as its author. It is therefore not patch-equivalent to the reviewed 320f31ff7: besides the new tests, vp_set.rs keeps one copy of the halt-latch guard and names the Halt helpers validate_restore_halt and restore_halt, like the VpSet methods that call them, with the same behavior.

Dependencies

• vmm_core: preserve halt state across snapshots nanvix/openvmm#129 should merge with 70dde4c65 preserved before this PR merges.

Validation

OpenVMM at 70dde4c65, with Rust 1.95.0 on Windows: cargo clippy --all-targets -p vmm_core (with and without --all-features, and with --tests --target aarch64-pc-windows-msvc for the aarch64 test topology), cargo doc --no-deps -p vmm_core, cargo nextest run -p vmm_core (40 passed, with and without --all-features), and cargo xtask fmt --fix pass.

NVX at cc02b7329, with OpenVMM built from 70dde4c65 by build-openvmm on each host and the guest artifacts of the v0.1.0-dev.c29f3d1b0329 release, whose guest inputs this PR does not change. scripts/nvx.py verify passes on every host.

Host	Backend	test-microvm (39 runs)	managed-exec-config, sandbox-lifecycle	test-aci-edge-sandboxes
prometheus32: bare-metal HPE DL380 Gen10, 2× Xeon Silver 4114, Ubuntu 26.04, Linux 7.0	KVM	passed	passed	15 passed
prometheus30: the same hardware, Azure Linux 3.0, Linux 6.6 mshv2	MSHV	passed	passed	15 passed
prometheus28: the same hardware, Windows Server 2025 Datacenter	WHP	passed	passed	15 passed
Laptop: Core i9-12900H, Windows 11 Enterprise	WHP	passed	passed	15 passed

The release packages do not include the sandbox scratch template, so the exec and lifecycle scenarios used one made with CI's mkfs.ext4 recipe.

Not run locally: test-openvmm-unit, test-openvmm, the --debug-kernel suite, verify-guest-determinism, and benchmark, which the CI matrix runs. Head: cc02b732989cbaf91400b7711e9e002c8aaac104.

[Copilot]

🔵 Needs a closer look

The runtime snapshot change requires human approval after the upstream dependency merges and exact-head CI completes.

0 open findings

What changed in this PR

Pins OpenVMM’s snapshot halt-state fix and records the new upstream position.

Changes:

• Updates the OpenVMM gitlink to 70dde4c65.
• Preserves and re-reports partition halt state after restoration.
• Adds roadmap position 309 for the pinned commit.

File	Description
openvmm	Pins the halt-state snapshot implementation and tests.
doc/​openvmm-upstream-roadmap.md	Updates pin metadata, counts, and roadmap position.

🧠 Review effort: Balanced

---

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