Skip to content

nvx-rs: give a clone's failures documented statuses - #937

Open
Enrique Saurez (esaurez) wants to merge 1 commit into
esaurez/842-pr2-repair-20261024from
esaurez/842-pr3-failure-statuses-20261024
Open

Enrique Saurez (esaurez) wants to merge 1 commit into
esaurez/842-pr2-repair-20261024from
esaurez/842-pr3-failure-statuses-20261024

Conversation

@esaurez

@esaurez Enrique Saurez (esaurez) commented Oct 27, 2026 •

Copy link
Copy Markdown
Contributor

Stacked on #936; this PR retargets when its parent merges.
Chain: #880 → #936 → this PR → #939 → #940 → #941, on dev; #879, #881, #885, #886, #877, #932, #884, #887, and #933 have merged.

Part of #842 (PR 3 of 3: failure statuses, and repair in the test adapter's guest).

What and why

A clone's guest that fails fast ends its VM with an exit status, from which the host classifies the clone's end. Only the time ABI's 193, 194, and 195 were defined, and the time ABI powers the VM off itself on a violation, so a guest init or agent that owns the VM's exit status and its shutdown could not report a repair's failure on its own terms. This documents one status for each class of a clone's failures, adds a strict mode to the time ABI, gives a repair's errors their status and progress, and has the runtime adapter's guest repair its clones.

The statuses: nvx::protocol::status

It compiles in every configuration, so the host's classifier and a guest's init can share it. Each status follows a diagnostic that names the failure; the host classifies a clone's end by both, since a workload may exit with any status.

Status Constant When
193 TIME_CONFORMANCE A conformance check of the time ABI failed
194 TIME_VIOLATION The time ABI's violation watcher observed a violation at run time
195 TIME_REPAIR The time ABI's part of a restore's repair failed
40 REPAIR_RESTORE The restore cannot be repaired: it holds no fresh entropy, or its capture finished it
41 REPAIR_PROCESSORS The online CPUs cannot be read, are not a prefix, or do not meet the processor target
42 REPAIR_MEMORY_TARGET The memory target is refused, before any block is added
43 REPAIR_MEMORY The activation of the memory target failed
44 REPAIR_RESEED The reseed of the kernel's random number generator failed
45 REPAIR_FINISH The restore's finish failed, other than by a violation of the time ABI
50 to 58 ACTIVATION_DEADLINE to ACTIVATION_ORDER Reserved, one for each class of a clone's activation's failures: the deadline, the host's session, the record, the expected resources, the root, the workload, the host export, the network settings, and the guest's own order

193, 194, and 195 keep their meanings. TIME_STATUSES, REPAIR_STATUSES, and ACTIVATION_STATUSES name the ranges, and describe returns what a status means.

Strict mode

TimeAbi::strict() selects it, and TimeAbi::is_strict() reports it: a violation that stops the VM in enforcing mode fails the call instead, after its event, with TimeError::Violation, and Violation::status() returns the status with which enforcing mode would have stopped the VM. It is for a caller that owns the VM's exit status and its shutdown. Report-only mode stays report-only.

  • The command tools keep enforcing mode, and so do the time daemon, whose failures no caller owns, and a capture's preparation, which runs as nvx-time pre-capture does. A failure of the deferred time work after the finish still stops the VM with the time ABI's own status.

A clone's repair

  • nvx::guest::clone takes the time ABI in strict mode for the capture and the repair.
  • RepairError::status() selects the failure's status: a violation of the time ABI's its own, 193 or 195, and every other cause the status of its class. The match is exhaustive in the crate, so there is no "unknown" status.
  • RepairError::progress() returns its RepairProgress: the memory blocks that the repair added and onlined, each counted once, whether it reseeded, and whether its finish started.

The runtime adapter's guest

  • In a clone that a restore of its template's snapshot started, the guest repairs the restore behind its closed fence, and ends with 31 once it repaired the clone, since it does not activate a clone yet, or with the status of the repair's failure. worker::capture::capture_status selects it; a capture request that the time ABI could not repair in a clone ends with the violation's status.
  • 31 keeps its number, so that a test that expects it keeps working, and now means a clone that the guest repaired and does not activate yet. Such a clone ends at once, with its fence closed, which may cut the deferred time work short.
  • The adapter's README documents the statuses, and a test checks that none of the guest's own statuses is the time ABI's, a repair's, or an activation's.

Validation

This head is the previous one, 3d8aed5, rebased onto #936's rebased head, 9831e19, so that it now also holds #936's fix of the acknowledgement's instant, with its own diff unchanged, and brings #933's rebase onto dev, OpenVMM at d2338ea2 and nvx-rs download among it; its per-commit checks and the checks below passed on it, and the tests grew only by the 55 that nvx-rs download adds to host::cli, under all features, and by #936's test of the acknowledgement's instant, under all features, in the guest binaries' checks, and as root.

On this head:

Linux x86_64:

  • nvx-rs: cargo fmt --check; Clippy with -D warnings, --all-targets --all-features, --lib, and --lib --no-default-features, and with each feature alone; cargo test --all-features (1562 passed), cargo test (804 passed), and the --lib --no-default-features build and test (260 passed); tests/host_modules.rs (22 passed); the bundled-artifacts test; rustdoc with -D warnings; the MSRV (1.89) check; the aarch64-apple-darwin check; the guest's tests and MSRV check with only guest.
  • Guest binaries: nvx.py check-guest-binaries (musl Clippy and tests, 876 passed), build-guest-binaries, test-guest-binaries (33 passed), check-static-elf.
  • tests/runtime-adapter: fmt, Clippy, build, tests, and MSRV in its protocol-only, host-only, and musl guest configurations.
  • scripts/check_markdown_links.py.
  • As root: the privileged capture test, the strict cold boot that stops at its violation, and the tests of guest::clone and guest::reseed (53 passed).

Windows (x86_64-pc-windows-msvc): nvx-rs fmt, Clippy (all features, --lib, no default features, and each feature alone), tests (all features 957 passed, default 819, no default features 260), tests/host_modules.rs, rustdoc, MSRV; tests/runtime-adapter in its protocol-only and host configurations; the Markdown links.

On 3d8aed5, with OpenVMM at e68871cc, the runtime adapter's VM suites: 58 of 58 passed on WHP and on MSHV (vm_layered 43, vm_template 9, vm_restart 3, vm_steps 3; on MSHV, on OpenVMM's host CPU profile, since the test host's CPU has no built-in one). No suite restores a clone yet, so the guest's repair runs in no VM here.

CI: ci.yml run 40617461513, dispatched on this head, since this chain's PRs don't target dev and get no PR CI, passed: 36 jobs succeeded, among them nvx-rs and the CLI on Linux and Windows, the guest artifacts, OpenVMM's unit tests and vmm-tests, the NVX microVM tests and the platform jobs on KVM, MSHV, and WHP; the 6 jobs that only pull requests or dev run were skipped. Before this rebase, ci.yml run 40588761279 passed on 3d8aed5.

Tests added:

  • The statuses are pinned, and each has a class and a meaning of its own.
  • Strict mode: a strict call fails with the violation that stops an enforcing one; a strict runtime keeps its first violation and never powers off; repair failures report their restore events and power off only when enforcing; strict mode keeps report-only mode and spares the daemon and the preparation; cold boot in strict and report-only mode; as root, a strict cold boot stops at its violation.
  • Repair: each failure class ends the clone with a status of its own; a violation of the strict finish is final; errors report how far the repair got; a block counts once, when the repair finds it added or online; the capture and the repair take the time ABI in strict mode.
  • The adapter: a capture request that the time ABI could not repair ends with the violation's status; the guest's own statuses collide with none of the reserved ones.

Left to #844's PR 5, as the issue says: the VM tests of memory targets and of deferred time work that ends after Ready.

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔵 Needs a closer look

Privileged restore, acknowledgement, and shutdown changes need human review alongside the pending full-gate and VM-suite results.

No open issues 🎉

What changed in this PR

This completes the failure-status portion of #842, building on clone repair with shared exit statuses, caller-controlled shutdown, and repair integration in the runtime adapter’s guest.

Changes:

  • Defines shared time, repair, and reserved activation statuses, with descriptions and collision tests.
  • Adds strict time-ABI calls and repair progress reporting while preserving enforcing behavior for command tools, capture preparation, and the daemon.
  • Repairs restored clones in the runtime adapter before exiting, keeping workload admission closed.
File Description
tests/​runtime-adapter/​src/​worker/​capture.rs Runs clone repair and selects outcome statuses.
tests/​runtime-adapter/​src/​template.rs Documents status 31 and checks reserved-status collisions.
tests/​runtime-adapter/​src/​bin/​runtime-adapter-guest.rs Updates worker documentation for repair outcomes.
tests/​runtime-adapter/​README.md Documents repair flow, shutdown behavior, and statuses.
nvx-rs/​src/​protocol/​status.rs Defines and tests shared failure statuses.
nvx-rs/​src/​protocol/​mod.rs Exposes the status module.
nvx-rs/​src/​lib.rs Updates the crate overview for statuses and repair.
nvx-rs/​src/​guest/​time/​system.rs Records strict-mode violations instead of powering off.
nvx-rs/​src/​guest/​time/​mod.rs Documents strict-mode shutdown ownership.
nvx-rs/​src/​guest/​time/​api.rs Adds strict calls and violation status reporting.
nvx-rs/​src/​guest/​clone/​tests.rs Checks strict-mode selection.
nvx-rs/​src/​guest/​clone/​repair/​tests.rs Tests failure statuses, progress, and retry accounting.
nvx-rs/​src/​guest/​clone/​repair.rs Tracks repair progress and assigns failure statuses.
nvx-rs/​src/​guest/​clone.rs Selects strict mode and documents caller responsibilities.
nvx-rs/​README.md Documents the new public APIs and behavior.

Review effort: Balanced

Add nvx::protocol::status, the exit statuses with which a clone's guest
ends its VM once it fails fast, and from which the host classifies a
clone's end: the time ABI's 193, 194 and 195, which keep their
meanings, one status for each other class of a clone's repair's
failures, 40 to 45, and one reserved for each class of a clone's
activation's failures, 50 to 58.

Add the time ABI's strict mode, TimeAbi::strict, for a caller that owns
the VM's exit status and its shutdown: a violation that stops the VM in
enforcing mode fails the call instead, after its event, with the
Violation, whose status is the one with which enforcing mode stops the
VM. The command tools keep enforcing mode, and so do the time daemon
and a capture's preparation.

nvx::guest::clone takes the time ABI in strict mode for the capture and
the repair. A RepairError reports the repair's RepairProgress, the
memory blocks that it added and onlined, its reseed, and its finish,
and selects its status, RepairError::status.

The runtime adapter's guest repairs a clone that a restore of its
template's snapshot started, behind its closed fence, and ends with 31
once repaired, since it does not activate a clone yet, or with the
status of the repair's failure.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot-Session: fbebd4aa-2ad7-427d-80ea-49358a645e9a

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants