scripts(aarch64): the six remaining QEMU launches take the host-wide lock (#834) - #845
Merged
Conversation
#834 found six scripts/ scripts launching qemu-system-aarch64 with 0 of them routed through docker/qemu/lib/qemu-host-lock.sh (#826/R181's own fix, scoped to docker/qemu/*.sh only). Each of the six now sources the helper and calls qemu_host_lock_acquire before its launch, with qemu_host_lock_track_pid registering the PID right after capture. Three of the six (run-arm64-qemu.sh, run-arm64-graphics.sh, run-aarch64-userspace.sh) ended their launch with `exec`, which would discard the lock's own EXIT trap before it could release -- exec is dropped for a plain foreground launch so the trap-based release still runs when QEMU exits; the interactive session itself is unchanged (same terminal, same Ctrl-A X exit). test_tracing_via_gdb.sh picks qemu-system-aarch64 or qemu-system-x86_64 at runtime, so the lock call is placed on its aarch64 leg only. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
A fresh `grep -rl qemu-system-aarch64 scripts/ docker/ run.sh` census (the same command #834's own issue body names) found two more real aarch64 launch sites beyond #834's own six named scripts: - docker/qemu-aarch64/run-arm64-boot.sh sits in a directory sibling to docker/qemu/, unreachable by the #826/R181 ratchet's own walk rooted at docker/qemu regardless of how its detection predicates are written. Wired the same way as docker/qemu/run-aarch64-test.sh's own Docker-wrapped launch (lock held around the host-side `docker run`). - run.sh's native (non-Parallels, non-VMware) arm64 launch. The Parallels and VMware code paths boot a VM, not a native QEMU process, and exit before reaching this launch line, so they are outside the lock's scope by construction. run.sh picks arm64 or x86_64 at runtime, so the lock call and PID tracking are guarded by the arm64 branch only. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
tests/qemu_host_lock_structure.rs walked docker/qemu only (#826/R181's own scope). Widens the walk to docker (recursive, reaching the docker/qemu-aarch64 sibling directory a docker/qemu-rooted walk cannot see) plus scripts (recursive) plus run.sh as a single named file. The anti-vacuity floor moves from 20 to 28, matching the exact count this branch's own two prior commits wired (20 pre-existing + 8 new). Adds a second mutation leg to qemu_host_lock_predicates_are_not_vacuous proving the widened scripts/ scope specifically: strips the real qemu_host_lock_acquire call from scripts/run-arm64-boot-test.sh's in-memory text (parallel to the pre-existing docker/qemu/ leg) and asserts the source line survives. Adds a reach check confirming the widened census lists docker/qemu-aarch64/run-arm64-boot.sh and run.sh by name. The detection predicate's own logic is unchanged; it already covers scripts/test_tracing_via_gdb.sh's indirect "$QEMU_BIN" launch via the QEMU_BIN=qemu-system-aarch64 assignment line that feeds it. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Round doc under docs/planning/green-program/gates/ recording what #834 disclosed, the fresh census that found two more launch sites beyond its six named scripts, the 8 scripts wired, why three lost their exec, the ratchet's widened census and its two mutation records (in-suite and a live on-disk mutation against the tracked scripts/run-arm64-boot-test.sh, reverted after observing the reddened suite), boot proofs (a quick-mode run of the cheapest newly-wired script and one strict-gate run), the 33-suite/593-test structural result, and what remains disclosed but not fixed (three .py launchers, one unreferenced .exp launcher, two pre-existing kill-by-pattern hazards). Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
F1 (blocking): the three interactive scripts (run-arm64-qemu.sh, run-arm64-graphics.sh, run-aarch64-userspace.sh) ran qemu-system-aarch64 as a plain foreground command after dropping `exec`. A direct-PID SIGTERM/SIGINT does not propagate to a foreground child, so it released the host lock while orphaning a running QEMU -- reproduced live against the real lock file, then fixed by backgrounding QEMU with an explicit 0<&0 (preserving the serial console's stdin) and qemu_host_lock_track_pid, matching the five already-correct wired scripts. Re-verified live with the real scripts/run-arm64-qemu.sh and a real kernel boot: a direct-PID SIGTERM now kills the tracked QEMU process and releases the lock. F2 (major): scripts/run-arm64-boot-test.sh's cleanup pkill ran before its own qemu_host_lock_acquire, so it could kill a different lock-holding script's in-progress boot; moved the acquire ahead of it. docker/qemu-aarch64/run-arm64-boot.sh's cleanup docker-killed by ancestor image instead of its own container; named the container per invocation and kill that name. A related, unfixed occurrence in docker/qemu/run-aarch64-interactive.sh (untouched by this branch) is reported on #829. F3 (major): parameterized OUTPUT_DIR (run-arm64-boot.sh) and SERIAL_OUTPUT (run-arm64-boot-test.sh) behind BREENIX_GATE_TMP (default /tmp), matching the #825 fix already applied to the sibling docker/qemu/run-aarch64-test.sh and run-aarch64-userspace.sh. F4 (minor): the original round's claim-lint receipt quoted an intermediate commit's file count; this round's own doc section re-quotes claim-lint's output at this round's own final state instead. Evidence: qemu_host_lock_structure.rs's 2 tests still pass; full 33-suite/ 593-case structural battery still green; live scripts/run-arm64-boot-test.sh quick and docker/qemu-aarch64/run-arm64-boot.sh both PASS with BREENIX_GATE_TMP pointed at a private scratch dir, 0 qemu-system-aarch64 processes and 0 breenix-arm64-boot-* containers left running after either.
…s round Merges origin/main (6432391) into gates/834-lock-wiring-scripts at the landing point and re-runs the round's own proof surface at the merge commit: all 33 tests/*_structure.rs suites (593 cases), scripts/ test_claim_lint.py, one script-default strict-gate batch (docker/qemu/run-aarch64-boot-test-strict.sh, 20/20 boots), and one docker/qemu/run-aarch64-prod-profile-boot-test.sh boot. No conflicts in the merge; no kernel/, gate-script, or tests/*_structure.rs file is touched by main's side. Landing re-smoke results are appended to the round's own doc.
ryanbreen
added a commit
that referenced
this pull request
Sep 6, 2026
…mpling origin/main advanced with #848 (sched/562-slice3e-pin-guard, the PIN_GUARD_ORACLE check) and #845/#827 (qemu-host-lock scripts widening, per-boot host facts) since this branch's merge-base. One real conflict, in docker/qemu/run-aarch64-boot-test-strict.sh's score_serial: this branch's RING_SPAN sampling-ratio check and main's PIN_GUARD_ORACLE check both append assertions to the same function tail. Resolved by keeping both hunks in sequence (RING_SPAN check first, then PIN_GUARD_ORACLE, then the shared `return 0`) so both gates the two branches added still run. Everything else auto-merged with no conflict.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
#826/R181's aarch64 QEMU host-wide lock (
docker/qemu/lib/qemu-host-lock.sh)was scoped to
docker/qemu/*.shby wording and by its structural ratchet(
tests/qemu_host_lock_structure.rs), which walked only that one directory.#834 disclosed six unwired
qemu-system-aarch64launch scripts underscripts/. A freshgrep -rl qemu-system-aarch64 scripts/ docker/ run.shcensus at this branch's start found two more real launch sites the issue did
not name:
docker/qemu-aarch64/run-arm64-boot.sh(a sibling directory outside theoriginal ratchet's walked root) and
run.shitself (named as acandidate in the issue body but not among its six counted scripts).
This branch wires 8 scripts into the lock (6 named by #834 + 2 found by the
fresh census), widens the structural ratchet's root and census to cover
them, and closes four review findings from a fix round (F1: three
interactive scripts dropped
execfor a backgrounded launch withoutqemu_host_lock_track_pid, so a direct-PID signal orphaned QEMU whilereleasing the lock; F2: two scripts' cleanup could kill a different
lock-holding script's in-progress boot; F3: two fixed
/tmppathsunparameterized behind
BREENIX_GATE_TMP; F4: a stale claim-lint receiptquote). New total: 28 wired launch sites (20 from #826/R181 + these 8).
Full account, live-boot proofs for both the newly-wired scripts and the
fix-round findings, and the structural-ratchet diff are in
docs/planning/green-program/gates/HOST-QEMU-LOCK-SCRIPTS-834-2026-09-05.md.Landing re-smoke
This PR also carries a merge of
main(6432391, no conflicts, nokernel//gate-script/tests/*_structure.rsfile touched by main's side)and a re-run of the round's own suites and gates at the merge commit, recorded
in the same doc's "Landing re-smoke" section:
tests/*_structure.rssuites: 33/33 green, 593 test cases.scripts/test_claim_lint.py: OK, exit 0.docker/qemu/run-aarch64-boot-test-strict.sh(script default, 20iterations): 20/20 boots succeeded, all
GATE_BOOT_FACTSlinesended_by=scored_pass.docker/qemu/run-aarch64-prod-profile-boot-test.sh: PASS, productionprofile reached
bsshdwith the futex-oracle seam absent,ended_by=scored_pass.Neither re-smoke boot hit a pre-adjudicated red signature.