Every write to SMI_CMD is made on the boot processor, by one function that reads its CPU beside the out

[Japabu]

Closes issues/the-kernel-writes-smi-cmd-from-whichever-cpu-its-caller-runs-on.md. Head 307bef0f6, on origin/main e16cb0841. Every T14 reading below is of 289906d5b, and git diff 289906d5b 307bef0f6 -- kernel tests src is empty (git diff --quiet on it exits 0; the output, zero bytes, is orch/smicmd-r3/kts.diff): the head adds one commit that touches issues/ alone, so the six boots stand for it. Log names are under the orchestrator's scratchpad, orch/.

What changed, per decision

• One function writes SMI_CMD, and it writes on cpu0. ACPI 6.5 Table 5.9 (read from the Internet Archive's capture of the specification; quoted in the module's header): "OSPM issues commands to the SMI_CMD port synchronously from the boot processor", and of ACPI_DISABLE, "writing ACPI_DISABLE to the SMI_CMD port from the boot processor". kernel/src/arch/x86_64/smi_cmd.rs declares the port and keeps it private, so the out in its answer is the only one the kernel can make to it; acpi_mode's enable and disable both go through smi_cmd::write.
• The CPU is read beside the out. answer closes interrupts, reads which CPU it is on and returns on any but cpu0; the check and the out are one CPU's whatever the caller holds. serve_here keeps only the relaxed owes hint. write issues its round, calls answer, and kicks cpu0 and spins only where the round is still unserved; there is no asked_from == BOOT branch.
• The mechanism is the one the counters round already uses: Shootdown's generation protocol answered from the kick handler. A caller off cpu0 stores the value, issues a round whose one target is cpu0, kicks cpu0 and spins until that round reads served; cpu0 writes from its kick handler, idle or busy. The tree has no affinity and no cross-call, and none is added.
• cpu0 also answers from a lock's spin (tlb::poll, one line). acpi_mode::release is reached from ops::close_all under the dying process's ProcessData lock, with preemption off. A cpu0 spinning on that lock with IF clear takes no kick; Lock::acquire already polls TLB shootdowns for that spinner, and now polls this too.
• The bound is time::DEAF_CPU, and its expiry is a panic, the TLB shootdown's rule for a CPU that takes no interrupt.
• The stop's guard moves with the write: smi_cmd::write refuses once quiesce::begun(), under the lock smi_cmd::settle waits out.
• Both lines say more: the CPU the out ran on, the CPU that asked, how long the out held the writer, and the writer's SMI count either side.
• The three T14 judges (counters, acpi_server_events, acpi_server_death) refuse a line whose writer is not cpu0.
• The acpi_server_death row's enable crosses CPUs by the job's doing. acpi_release starts threads in turn until one reads a non-zero x2APIC id (CPUID leaf 0BH, EDX) as its first act, and that thread claims; the judge refuses an enable asked from cpu0. 64 starts without one is the job's panic. Measured before building on it, under QEMU on a two-CPU TCG guest with a temporary patch to stop_short (restored; orch/smicmd-r2/probe3.patch, probe3.log): one of the first four threads started in turn read a non-zero id and one of twenty-four read zero, so the leaf answers for the CPU the thread is on and a spawn leaves cpu0 within four starts there.

The T14, at 289906d5b

Six unattended boots by the orchestrator (orch/t14-748r2.log; the record is the pull request's comment 6048082355): each image's sha256 checked against orch/smicmd-r2/images.sha256 before its flash, the worktree clean at 289906d5b before every boot and every judgement, every boot rc 0, nobody at the machine. Each judged by cargo test --test toyos-build -- --metal --metal-readback <dir> <filter>, <dir> under orch/smicmd-r2/.

boots	<dir> and filter	exit	the judge's last line	log
shared, shared-debug, testcases	metal-counters, counters	0	[metal] 3 passed, 0 failed, 3 boot(s)	metal-counters/judge-counters.log
acpicase, testcases-hold	metal-acpi_server, acpi_server_	0	[metal] 2 passed, 0 failed, 2 boot(s)	metal-acpi_server/judge-acpi_server_.log
the mutation's acpicase, built from ca386eedb	mutation/metal-acpi_server, acpi_server_death	1	[metal] 0 passed, 1 failed, 1 boot(s)	mutation/metal-acpi_server/judge-acpi_server_death.log

(a) counters: PASS counters. Its testcases boot's line:

acpi: ACPI mode: ACPI_ENABLE 0xf0 written to SMI_CMD 0xb2 on cpu0, asked from cpu0; the write held cpu0 2078830ns, its SMI count 4823 before the write and 4824 after; SCI_EN set 13081ns after

The writer is cpu0 and its SMI count moved by one across the write. The judge's loaded: cpu0 kick late p50=0.1us p99=9.1us max=17.0us, beside the last recorded 0.2 / 9.6 / 22.9 µs and round 1's 0.3 / 9.1 / 16.6 µs at 448107b54. The shared and shared-debug boots' lines read the same shape, cpu0 both, held 2049678 ns and 2063963 ns.

(b) acpi_server_death: PASS acpi_server_death. Its acpicase boot's two lines:

acpi: ACPI mode: ACPI_ENABLE 0xf0 written to SMI_CMD 0xb2 on cpu0, asked from cpu1; the write held cpu0 2087832ns, its SMI count 4819 before the write and 4820 after; SCI_EN set 14127ns after

acpi: legacy mode again: ACPI_DISABLE 0xf1 written to SMI_CMD 0xb2 on cpu0, asked from cpu2; the write held cpu0 146295ns, its SMI count 4820 before the write and 4821 after; PM1a_CNT reads 0x0000 15084ns after, SCI_EN clear

Both name cpu0 as writer and both askers are off it, so the kick and the wait ran for each write; SCI_EN read clear after the disable. The enable's asker is the job's doing: its first thread ended on cpu0 without claiming, its second claimed, and the job said acpi_release: claimed from the CPU of x2APIC id 2, the kernel's cpu1. The disable's asker is the scheduler's doing; the judge prints it and requires nothing of it.

(c) acpi_server_events: PASS acpi_server_events. Its testcases-hold boot's line:

acpi: ACPI mode: ACPI_ENABLE 0xf0 written to SMI_CMD 0xb2 on cpu0, asked from cpu0; the write held cpu0 2052523ns, its SMI count 4817 before the write and 4818 after; SCI_EN set 12625ns after

The boot held to its end untouched: one embedded-controller query, 0x4f, no button press and no Shutdown; the server's last word is 28 SCIs; embedded controller queries taken: 0x4f x14. Round 1's red of this row at 448107b54 was a person's press: the owner was at the machine for another measurement and, through the orchestrator's scheduling error, pressed the power button during that boot (query 0x28, the press served, the supervisor's Shutdown).

What an SMI costs, and why cpu0 pays

Tracked readings (issues/the-t14s-firmware-interrupts-every-cpu-every-2-2-s-under-toyos.md): the enable moved the SMI count on every CPU alike, so the firmware's handler stops all of them whichever CPU writes. The out does not retire until the handler returns, so the writer sits in it where the write was made: cpu0's kick handler or its own syscall, interrupts closed. Read at 289906d5b: the enable's out held cpu0 2.05 to 2.09 ms on five boots, the disable's 0.15 ms on one (0.22 ms on round 1's one). cpu0 is where device interrupts land, so they wait that long, as they do under every SMI. cpu0 pays because the specification names it and the firmware was written against that.

The cost with no round in flight. serve_here is called from the kick handler and, through tlb::poll, on every iteration of every contended Lock spin on every CPU. It is the owes hint: two relaxed loads, a compare and a branch, on every CPU alike. At 448107b54 it was a load of the CPU id, a test and a branch off cpu0, and those plus the hint on cpu0 (orch/smicmd/kick.dis, where the hint is the two loads, cmp and jbe). This head's kernel was not disassembled; the count is read from the source and that listing. While a round is in flight, about the 2 ms above, a kick or a spin on any CPU also closes interrupts and reads its CPU id in answer. The counters judge's kick lateness, in (a), reads no cost from it.

Which tier reaches what

• QEMU reaches none of the write. OVMF hands q35 over in ACPI mode, so no guest's claim writes SMI_CMD. The guest suite shows only that the kick handler, the lock spin and the claim path still work with nothing owed.
• The T14 reaches both writes, and the cross-CPU path on the acpicase boot's enable by the job's arrangement.
• No host test: the protocol is Shootdown's, which kernel/loom already models.

Checks (high-risk: the kernel, a device)

• Independent oracle: the T14, above, at 289906d5b.

• The mutation, booted: red, exit 1. Commit ca386eedb (branch wt/toyos-smicmd-mutation, never to land): 289906d5b plus one hunk, three deletions in smi_cmd.rs, the if percpu::cpu_id() != BOOT { return; } out of answer, so write answers its own round on the caller's CPU. The patch is orch/smicmd-r2/mutation.patch and the pull request's comment 6047876901. Its acpicase boot, judged by acpi_server_death at the head: exit 1,

  FAIL acpi_server_death: SMI_CMD was written on cpu1, not on the boot processor: […] acpi: ACPI mode: ACPI_ENABLE 0xf0 written to SMI_CMD 0xb2 on cpu1, asked from cpu1; the write held cpu1 2050966ns, its SMI count 4822 before the write and 4823 after; SCI_EN set 16558ns after

  and its disable reads on cpu2, asked from cpu2, held 145058 ns. The asker was off cpu0, so the boot is a control: the same job on a kernel without the check writes where it was asked, and the judge refuses it. counters and acpi_server_events are not its judges: their asker is cpu0 unless the scheduler says otherwise.

• Negative control, on a recorded real failure (round 1, at 448107b54): that head's judges over the T14's readbacks of the kernel without the change (922a6b7c7, whose acpicase boot wrote the enable from cpu7): acpi_server_ exit 1, counters exit 1 (orch/smicmd/negctl-acpi_server.log, negctl-counters.log). Red by the line's shape: that kernel's line names no writer.

• The judge's number, on a hand-edited line (round 1): the line rewritten naming cpu0 judges green, naming cpu7 red. Synthetic; the edit is the pull request's comment 6047204769.

Gates

gate	head	result	where
host (cargo run -- --ci host)	289906d5b	success, 17m24s	CI run 37694597078
guest / suite	289906d5b	success, 14m27s	CI run 37694597078
toolchain / build	289906d5b	success	CI run 37694597078
… --metal --metal-readback metal-counters counters	289906d5b	exit 0	orch/smicmd-r2/metal-counters/judge-counters.log
… --metal --metal-readback metal-acpi_server acpi_server_	289906d5b	exit 0	orch/smicmd-r2/metal-acpi_server/judge-acpi_server_.log
… --metal --metal-readback mutation/metal-acpi_server acpi_server_death	the judge at 289906d5b, the image from ca386eedb	exit 1, the red asked for	orch/smicmd-r2/mutation/metal-acpi_server/judge-acpi_server_death.log
cargo run -- --build-only	the working tree before its commit, whose sources are 289906d5b's	exit 0	orch/smicmd-r2/build-wip.log
cargo run -- --ci host	448107b54	exit 0	orch/smicmd/host.log
cargo test (the guest suite: 30 passed, 30 total)	448107b54	exit 0	orch/smicmd/guest.log

The run's headSha is 289906d5b. The three judges' exits are in orch/t14-748r2.log. Nothing was built or run locally at 307bef0f6, by the owner's restriction on this machine's compute: it differs from 289906d5b in issues/ alone, and its host is the check CI runs on its push. Host load across round 1's guest suite: 15 to 42 (1-minute average).

Recorded, not removed

issues/no-t14-row-arranges-an-acpi-disable-asked-off-the-boot-processor.md, three items:

• The disable's asker is the killed server's last thread, on the CPU the kill found it on, which the job does not place. 289906d5b's boot read it asked from cpu2, so the wait under the dying process's lock has run on the machine once, by the scheduler's doing; of the three boots whose line names the asker, round 1's read asked from cpu0. The judge prints the asker and does not require it: a judge that required a crossing no job arranges would be a flake.
• No row reads cpu0's answer from a lock's spin, and no line says whether a write was answered from the kick or from a spin.
• The job's arrangement of the enable's asker has a window: a preemption between the claiming thread's read of its id and the kernel's lock. With no affinity in the tree it cannot be closed. Neither boot of the job hit it (asked from cpu1, claimed from the CPU of x2APIC id 2 on both). A boot that does reds the row as FAIL acpi_server_death: the job's claim was asked from the boot processor, so no CPU asked it for this write: over an enable line on cpu0, asked from cpu0, beside the job's line naming a non-zero id; the file says so, so that red is recognised and not re-run.

Its exit: a judge that refuses asked from cpu0 on the disable over a job that arranges it, a kernel line that names a spin's answer, and an asker held to its CPU from its read to the kernel's taking of the request.

issues/nothing-reads-whether-an-sci-source-is-enabled-when-acpi-disable-is-written.md: the closed issue's one open note.

issues/the-acpi-row-is-released-with-an-acpi-disable-the-firmware-has-not-answered.md stays open and untouched: no tier reaches the handback's expiry.

Where this differs from the stage design's K7 proposal

• It has callers that may park do so with a deadline, and leave fall back past its bound. Here every caller spins and the expiry is a panic: one path, and no request left standing after its caller has gone.
• Its witness type is the port's privacy and answer's own read of the CPU.

Unsure of

• How often the job's window is hit. Two boots of the job, neither hit it; that is no rate. It is recorded in the issue above with what its red reads.
• The job takes x2APIC id 0 for the boot processor. The judge holds the kernel's own asked from, so a machine where that is false reds the row and passes nothing.
• Shootdown::owes is a relaxed hint, as it is for the counters round's kick. A cpu0 that read it stale would ignore its kick and the caller would panic at DEAF_CPU. An interrupt's delivery orders it on x86; nothing models it.

🤖 Generated with Claude Code

https://claude.ai/code/session_01RvnWQFcMuGqTHYhvSnTe8A

[Japabu]

The hand edit behind "the judge's number, on a hand-edited line" at 448107b54. Applied to copies of the acpicase and testcases-hold readbacks of 922a6b7c7, with w 0 and then 7; each copy then judged with cargo test --test toyos-build -- --metal --metal-readback <copy> acpi_server_. w=0: exit 0, PASS acpi_server_events, PASS acpi_server_death. w=7: exit 1, both FAIL … SMI_CMD was written on cpu7, not on the boot processor. The tree was clean after each.

s, n1 = re.subn(
    r"written to SMI_CMD 0xb2, SCI_EN set (\d+ns) after; cpu(\d+)'s SMI count (\d+) before the write and (\d+) after",
    lambda m: f"written to SMI_CMD 0xb2 on cpu{w}, asked from cpu{m.group(2)}; the write held cpu{w} 0ns, "
              f"its SMI count {m.group(3)} before the write and {m.group(4)} after; SCI_EN set {m.group(1)} after", s)
s, n2 = re.subn(
    r"ACPI_DISABLE 0xf1 written to SMI_CMD, PM1a_CNT",
    f"ACPI_DISABLE 0xf1 written to SMI_CMD 0xb2 on cpu{w}, asked from cpu0; the write held cpu{w} 0ns, "
    f"its SMI count 0 before the write and 0 after; PM1a_CNT", s)

Substitutions made: acpicase/kernel.log 1 and 1, testcases-hold/kernel.log 1 and 0.

The unedited readbacks, same command: acpi_server_ exit 1 ("acpi: ACPI mode: ACPI_ENABLE 0xf0 written to SMI_CMD 0xb2 " never reached either kernel log), counters exit 1 (no record carrying " written to SMI_CMD 0xb2 on cpu" and then ", asked from cpu").

[Japabu]

Review of 448107b54 against origin/main e7010129f, round 1. Read only: no build, no test, nothing changed in the tree.

Net lines (git diff --shortstat origin/main...448107b54): 9 files, +245 −103. Production (kernel/) +194 −59; tests +22 −6; issues/ +29 −38. The growth is the round and the four words the line and the judges read; accepted, less what the first NOTE removes.

BLOCKER

• PR body, "Checks" and "Gates" — no reading from the metal machine at this head is in the body, and the close's exit rests on one — issues/the-kernel-writes-smi-cmd-from-whichever-cpu-its-caller-runs-on.md is deleted on an exit that asks for the two kernel lines of the acpi_server_death boot. What the body must carry, each with its command, exit and the line itself: (a) counters, exit 0, its enable line naming cpu0 as writer, the writer's SMI count moving by one across the write, the write held cpu0 figure, and the judge's cpu0 kick late p50/p99/max beside the recorded 0.2 / 9.6 / 22.9 µs; (b) acpi_server_death, PASS, both lines naming cpu0 as writer, SCI_EN read clear after the disable, and at least one of the two reading asked from cpuN with N not 0: a boot whose two askers are both cpu0 ran answer() directly from write and measured neither the kick nor the wait, so it does not meet "by construction" for the path this change adds; (c) acpi_server_events, PASS, its enable line naming cpu0.
• tests/toyos.rs:453 (acpi_server_events) — red at this head on the metal machine, by the orchestrator's readback in orch/smicmd/metal-acpi_server/ (judge-acpi_server_.log: 1 passed, 1 failed, 2 boot(s), exit status 1) — the testcases-hold boot never reported: its kernel log ends 27.7 s into acpi_hold's 54 s hold with an embedded-controller query 0x28 taken for the first time, then four seconds later the power button was pressed, on SCI 29 of this boot and the supervisor's Shutdown. The same image's boot of the base (922a6b7c7) took only query 0x4f and held to 54 s. A red row is a defect until it is explained: the body says whether a person pressed that button; if one did, the row is run again untouched and reads exit 0; if nobody did, this head raises a press the base did not and does not land.
• kernel/src/arch/x86_64/smi_cmd.rs:100 — the mutation was not run and two of the three judges cannot red on it — patch: if asked_from == BOOT { becomes if true {, so every caller answers its own round on its own CPU. counters and acpi_server_events stay green under it on every recorded boot (asker cpu0 each time); only acpi_server_death reds, and only when its asker is off cpu0. It must turn acpi_server_death red, exit 1, with SMI_CMD was written on cpuN, not on the boot processor, on an acpicase boot whose line reads asked from cpuN, N not 0. The implementer supplies the patch as a commit off this head; the orchestrator boots it, since the machine is his. No person is needed: the acpicase job claims from its own thread, and every recorded boot of that image, this head's included, had it on cpu7. A mutated boot that reads asked from cpu0 is no control and is booted again. The controls in the body are a red by the line's shape and a hand-edited line; neither is a kernel that wrote from the wrong CPU.
• tests/toyos.rs:3775 (smi_cmd_writer) and kernel/src/arch/x86_64/tlb.rs:164 — a compromise the branch found and did not record — nothing holds the asker off cpu0 (the body's "Unsure of" says so), so the cross-CPU path is measured by the scheduler's habit on one image; and no boot on record, this head's included, has an ACPI_DISABLE asked from another CPU, so the release under the dying process's lock across CPUs, and the answer from tlb::poll that exists for it, have run on no machine. Either the acpicase job puts its claimant off cpu0 before it claims (CPUID leaf 0BH gives a Ring 3 thread its own x2APIC id) and the judge then requires a crossing, or this is an issues/ file with an owner, the four boots as evidence, and an exit a row can read. A judge that requires a crossing the job does not arrange is a flake and is not the fix.

NOTE

• kernel/src/arch/x86_64/smi_cmd.rs:128-130,137 — the port's privacy is as strong as a witness for "one out" and weaker by one step for "on the boot processor" — pio::Port is minted only from a Declared, pio::declare refuses the port a second time, and PORT is private, so no other code can reach the port: that half holds. But serve_here is pub and reads cpu_id() == BOOT before answer closes interrupts; the check and the out stay on one CPU only because each of today's three call sites has preemption off (the handler, Lock::acquire's spin, write under WRITING). Read the CPU inside answer, under its guard, and return where it is not the boot processor; serve_here keeps only the owes hint; write calls answer() and kicks only where the round is still unserved. Then the check stands beside the out, the asked_from == BOOT branch and the mutation's site are gone, and the kick handler pays the same loads.
• PR body, "the kick handler's cost" — true of the handler (orch/smicmd/kick.dis: load, test, branch off cpu0; four more on cpu0 owing nothing) and silent that tlb::poll now runs the same on every iteration of every contended Lock spin on every CPU.
• PR body, "Gates" — the three exits are true of 448107b54 (gates.head, gates.exits; host.log ends 77 step(s), all green, guest.log 30 passed, 30 total) and the body names no log for any of them.

Asked of this round

• Deadlock and lost wake-up: none found by reading. Every spin that waits on something the caller holds is Lock::acquire's, which polls. The spins that do not poll wait on nothing the caller holds: tlb::wait_for on the caller's flush, which the caller's own tlb::poll at smi_cmd.rs:113 answers, and that line is load-bearing; the serial lock, which the caller does not hold while it waits; device waits, bounded by the device. A kick taken between the hint and answer's mask writes once: the second serve_if_owed finds nothing owed. ASKED is ordered by the round's own acquire. The lock spin already read the CPU id before this change, so the unconditional read in poll adds no early-boot hazard.
• Two callers: serialised by WRITING; a second caller that is cpu0 answers the first from its spin.
• The stop: unchanged in substance; a stop's caller on cpu0 answers a write in flight from settle's own spin.
• Expiry, and K7: the implementer is right on both counts. Parking buys nothing here: the firmware's handler stops every CPU for its span, so a parked caller's CPU sits in it too, and what is left to save is a kick's latency against a wake path added to the handler. A fallback past the bound leaves a request cpu0 can serve after the row has gone to another holder, or after settle returned to the power-off, and is the second path this bar refuses; a cpu0 deaf for DEAF_CPU already panics the next TLB shootdown. K7's witness "constructible only inside that handler" cannot exist beside K7's own same-CPU path.

SEND BACK

[Japabu]

The mutation review round 1 asks for, in the shape of the round-2 head 289906d5b: commit ca386eedb on wt/toyos-smicmd-mutation, never to land. Applied with git apply --check and committed from a detached head; its acpicase image staged with cargo test --test toyos-build -- --metal --metal-readback <dir> acpi_server_death, exit 2 (staged, builds); the branch checked out again, tree clean. Not booted: the machine is the orchestrator's. It must read acpi_server_death red, exit 1, on SMI_CMD was written on cpuN, not on the boot processor, N not 0.

--- a/kernel/src/arch/x86_64/smi_cmd.rs
+++ b/kernel/src/arch/x86_64/smi_cmd.rs
@@ -139,9 +139,6 @@
 /// allocates nothing.
 fn answer() {
     let _closed = IrqGuard::close();
-    if percpu::cpu_id() != BOOT {
-        return;
-    }
     ROUND.serve_if_owed(BOOT as usize, || {
         let port = PORT.get().expect("smi_cmd: a write asked of a machine whose FADT names no SMI_CMD").port(0);
         let value = ASKED.load(Relaxed);

The temporary patch behind the x2APIC measurement (applied, run with cargo test --test toyos-build -- machine_shutdown_short_stop, reverted; the job reaches its power-off only where the assertion held, and the run's red is the stop left no thread running, which is past it):

--- a/tests/common/power.rs
+++ b/tests/common/power.rs
@@ -76,7 +76,6 @@
     );
     let options = BootOptions {
         qmp: true,
-        smp: 1,
         kernel_params: &["stop-budget-spent"],
         extra_root_files: vec![("bin/test_rs_stop_short".to_string(), short)],
         ..Default::default()
--- a/tests/toyos-rust-tests/src/bin/stop_short.rs
+++ b/tests/toyos-rust-tests/src/bin/stop_short.rs
@@ -5,10 +5,14 @@
 
 use toyos::power::{stop, Stop};
 
+#[path = "../arch/cpu.rs"]
+mod cpu;
+
 fn main() {
-    std::thread::spawn(|| loop {
-        std::hint::spin_loop();
-    });
+    let ids: Vec<u32> = (0..24)
+        .map(|_| std::thread::scope(|threads| threads.spawn(cpu::x2apic_id).join().expect("probe thread")))
+        .collect();
+    assert!(ids[..4].iter().any(|&id| id != 0) && ids.iter().any(|&id| id == 0), "PROBE {ids:?}");
     let refused = stop(Stop::Shutdown);
     panic!("stop_short: the power-off was refused: {refused:?}");
 }

[Japabu]

T14 at 289906d5b, run by the orchestrator: six unattended boots, each image's sha256 checked against the request before its flash, the worktree clean at the head before every boot and judgement, every boot rc=0. Nobody touched the machine.

boots	judge	exit
acpicase, testcases-hold	--metal --metal-readback … acpi_server_	0, [metal] 2 passed, 0 failed, 2 boot(s)
shared, shared-debug, testcases	… counters	0, [metal] 3 passed, 0 failed, 3 boot(s)
the mutation's acpicase (built from ca386eedb: the CPU check removed from answer)	… acpi_server_death	1: SMI_CMD was written on cpu1, not on the boot processor

The kernel's lines:

• acpicase: ACPI_ENABLE 0xf0 written to SMI_CMD 0xb2 on cpu0, asked from cpu1; the write held cpu0 2087832ns, its SMI count 4819 before the write and 4820 after; SCI_EN set 14127ns after
• acpicase: ACPI_DISABLE 0xf1 written to SMI_CMD 0xb2 on cpu0, asked from cpu2; the write held cpu0 146295ns, its SMI count 4820 before the write and 4821 after; PM1a_CNT reads 0x0000 15084ns after, SCI_EN clear
• testcases-hold: enable on cpu0, asked from cpu0, held 2052523 ns, 4817 to 4818; this boot held to its end untouched.
• counters (testcases): enable on cpu0, asked from cpu0, held 2078830 ns, 4823 to 4824.
• the mutation: enable on cpu1, asked from cpu1, held 2050966 ns; disable on cpu2, asked from cpu2.

So both writes crossed CPUs at the head (the enable from cpu1, the disable from cpu2), and the same job with the check removed writes where it was asked.

[Japabu]

Review of 289906d5b against origin/main e16cb0841, round 2. Read only: no build, no test, nothing changed in the tree. Read: the three commits, the whole diff, every changed file at the head, the round-1 to round-2 delta, the orchestrator's run log and the six readbacks' kernel logs and judge logs, the mutation commit, and the head's CI run.

Net lines (git diff --shortstat origin/main...289906d5b): 12 files, +355 −104. Production (kernel/) +200 −59; tests +78 −7; issues/ +77 −38. Since round 1 the kernel moved +6 on smi_cmd.rs (the CPU read moved into answer, the asked_from == BOOT branch gone) and the tests +56 for the job's placement and the judge's refusal; accepted, both are what round 1 asked for.

Round 1's BLOCKERs

1. No reading from the metal machine at the head: CLOSED, by the orchestrator's six boots of 289906d5b (PR comment 6048082355; the orchestrator's run log, every boot rc 0, each image's sha256 equal to orch/smicmd-r2/images.sha256, staged at stage.head 289906d5b).
   • (a) counters: exit 0, [metal] 3 passed, 0 failed, 3 boot(s) (metal-counters/judge-counters.log). Its enable reads on cpu0, asked from cpu0, held cpu0 2078830 ns, SMI count 4823 to 4824. cpu0 kick late p50=0.1us p99=9.1us max=17.0us, beside the recorded 0.2 / 9.6 / 22.9 and round 1's 0.3 / 9.1 / 16.6: the handler's added call costs nothing this judge can read.
   • (b) acpi_server_death: PASS, in a command that exits 0. Enable on cpu0, asked from cpu1, held 2087832 ns, 4819 to 4820; disable on cpu0, asked from cpu2, held 146295 ns, 4820 to 4821, PM1a_CNT reads 0x0000 15084ns after, SCI_EN clear. Both writers cpu0, both askers off it: the kick and the wait ran for each write. The job's own log shows the arrangement working and not merely lucky: its first thread ended on cpu0 without claiming, its second claimed (claimed from the CPU of x2APIC id 2, the kernel's cpu1).
   • (c) acpi_server_events: PASS, enable on cpu0, asked from cpu0, held 2052523 ns.
2. acpi_server_events red: CLOSED. The same row, untouched, at this head: [metal] 2 passed, 0 failed, 2 boot(s), exit 0 (metal-acpi_server/judge-acpi_server_.log). Its testcases-hold kernel log holds one embedded-controller query, 0x4f, no 0x28, no button press and no Shutdown; the server's last word is 28 SCIs; embedded controller queries taken: 0x4f x14 at 43.3 s. The body's account of round 1's press stands.
3. The mutation not run: CLOSED. ca386eedb is this head plus one hunk, three deletions in smi_cmd.rs (the CPU check out of answer; orch/smicmd-r2/mutation.patch is that diff). Its acpicase boot judged by acpi_server_death: exit 1, FAIL acpi_server_death: SMI_CMD was written on cpu1, not on the boot processor, on a line reading on cpu1, asked from cpu1; its disable reads on cpu2, asked from cpu2 (mutation/metal-acpi_server/judge-acpi_server_death.log). The asker was off cpu0, so it is a control, and it is a kernel that wrote from the wrong CPU, which round 1's two were not. The site moved with round 1's first NOTE; the mutation moved with it and is the right one for this head.
4. The cross-CPU path left to the scheduler, unrecorded: CLOSED. The job claims from a thread that read a non-zero x2APIC id (acpi_release.rs:33-48), the judge refuses an enable asked from cpu0 (tests/toyos.rs, acpi_death_on_metal), and both ran on the machine, green at the head and red under the mutation. The disable's asker and the spin's answer are recorded in issues/no-t14-row-reads-an-acpi-disable-asked-off-the-boot-processor.md with an owner that exists and an exit a judge can read.

Round 1's NOTEs

• The check beside the out: done as asked (smi_cmd.rs:141-145). answer closes interrupts and then reads the CPU; serve_here is the hint alone; write kicks only where its round is unserved. Read again for what the move could break: on cpu0 write's own answer either serves or finds a kick's answer already published, and the served read then skips the kick; off cpu0 it returns after one masked read; no path writes twice or not at all.
• The body now says what tlb::poll costs every spinner.
• The body now names a log for each gate.

The host and guest suites at this head

Not run locally. CI ran them on 289906d5b, run 37694597078 (headSha read from the run): host, which is cargo run -- --ci host, concluded success in 17m24s; guest / suite concluded success in 14m27s; toolchain / build success. That is what each had to show, and it shows it. The guest suite reaches none of the write (the body says why, and it is true: the firmware QEMU boots hands over in ACPI mode); what it holds is that the kick handler, the lock spin and the claim path still work with nothing owed.

BLOCKER

None.

NOTE

• PR body, the metal section headed for 448107b54, "Checks", "Gates", "Unsure of" — the body carries round 1's readings and says this head's are "requested, not taken", the mutation is "for the orchestrator to boot", host and guest / suite are owed, and "no boot of the new job exists yet" — each is false of the record now, and the body becomes main's commit. Before the queue it carries, for 289906d5b: the three judges' commands, exits and the lines above; the mutation's exit 1 and its line; the CI run's two conclusions. Ranked a NOTE and not the Evidence BLOCKER because every one of those measurements exists at this head, on this pull request, with its log, and was read here from the log; what is missing is its place.
• issues/no-t14-row-reads-an-acpi-disable-asked-off-the-boot-processor.md — its title, slug and third paragraph are false of the record since the head's own boot: the row read a disable on cpu0, asked from cpu2, so "the one boot of a kernel whose line names it reads asked from cpu0" and "the wait under the dying process's lock has run on no machine" no longer hold. The file stays open: its exit is unmet, since nothing arranges that asker and of the three boots whose line names the asker, round 1's did not cross. The judge must not require it: a judge that requires a crossing no job arranges is a flake, which is this file's own exit. It stays a reading the judge prints. Correct the paragraph with the head's line and the mutation's (on cpu2, asked from cpu2), say the wait has run once and by the scheduler's doing, keep "neither has the spin's answer" only as far as it is known (the line does not say which path answered), and rename the slug from "reads" to what is true, "arranges", moving the body's citation of it.
• tests/toyos-rust-tests/src/bin/acpi_release.rs:28-32 and the same issue file — the job's arrangement has a window (a preemption between the thread's read of its id and the kernel's lock), named in a source comment and in the body's "Unsure of" and in no issue. A compromise found is removed or recorded: with no affinity in the tree it cannot be removed, so it goes in that file as a third item, with the two boots that did not hit it as evidence and what a red from it reads (the job's claim was asked from the boot processor), so the first such red is recognised and not re-run.
• An issues/-only commit for the two lines above leaves the six boots standing as this change's hardware reading only if git diff 289906d5b <new head> -- kernel tests src is empty; the body then says so, and host runs again on the new head.

LAND AFTER NAMED CHANGES