cargo test cannot pass: 12 shared-QEMU host targets nest a cargo invocation inside cargo test and time out

[ryanbreen]

Summary

cargo test cannot pass on this repository. Twelve host test targets fail on
both machines — the ARM Mac and the beast x86 VM — and they fail for a
structural reason, not a flake: the shared-QEMU harness they all use shells out
to a nested cargo invocation from inside cargo test, which blocks on the
outer build lock until the harness's own safety timeout expires.

tests/shared_qemu.rs:65 launches the kernel with

Command::new("cargo").args(&["run", "--features", "testing", "--bin", "qemu-uefi", ...])

The outer cargo test already holds the target-directory lock, so the inner
cargo run waits for it. The harness gives the boot a 5-second POST_COMPLETE
deadline and a 30-second overall safety timeout, then gives up.

Observed, 2026-08-28, at main @ 70c33b0

Beast (breenix-x86, x86_64, where these x86 tests belong):

⏳ Check #25: Waiting for checkpoint 'POST_COMPLETE' (timeout: 5s, elapsed: 2.53s)
⚠️  Safety timeout reached after 30 seconds
✅ Captured 0 bytes of kernel output for all tests

Zero bytes: QEMU never produced output at all, which is what a blocked nested
cargo looks like.

ARM Mac (x86_64 kernel under TCG):

⚠️  Checkpoint timeout: Waiting for checkpoint 'POST_COMPLETE' (timeout: 5s, elapsed: 5.07s)
✅ Captured 1976 bytes of kernel output for all tests

1976 bytes: the boot started but was nowhere near POST inside five seconds.

Twelve targets fail identically, all of them shared-QEMU users (cargo test --release --no-fail-fast, 29 targets green, 12 red):

async_executor_tests, boot_post_test, exception_tests, guard_page_tests,
interrupt_tests, keyboard_tests, logging_tests, memory_tests,
ring3_smoke_test, syscall_tests, system_tests, timer_tests.

Seventeen test files reference shared_qemu in total, so the blast radius is
slightly larger than the twelve currently observed to fail.

Reproduced with the branch checked out and with main checked out — this
predates any current work.

Why it matters

"All host suites green" is not currently a statement anyone can make, so the
host suite cannot be used as a gate, and a genuine regression landing in one of
these twelve targets would be invisible under twelve pre-existing reds. The
29 targets that DO pass are the source-scanning ratchets and structure tests;
every test that actually boots a kernel from cargo test is dark.

Suggested shape

Three options, in preference order:

1. Stop nesting cargo. Have the harness exec the already-built
   target/release/qemu-uefi binary directly (the way
   docker/qemu/run-x86-gate.sh does) and require the caller to have built it,
   failing loudly with a build instruction if it is missing. This removes the
   lock conflict entirely.
2. Make the deadlines honest. Five seconds for an x86 TCG boot to reach
   POST_COMPLETE is not a real budget on either machine; the boot gates that
   work use 150-900 seconds.
3. Retire what cannot be revived. If a suite is superseded by the boot-test
   registry, delete it rather than leaving it permanently red.

Whichever is chosen, the acceptance is the same and should be stated up front:
cargo test --release --no-fail-fast reports zero failed targets on beast, and
the Mac's expectation for the x86-only ones is documented rather than assumed.

Found while building the ext2/VFS fault-injection leg (green program, arc 2),
whose own host-suite ratchet is one of the 29 that pass.