Nine defects in the kernel's high-risk areas, each closed with a measured control

issues/build/syscall-window-nmi-reds-under-a-shared-host.md

@@ -0,0 +1,51 @@
+---
+status: open
+kind: defect
+opened: 2026-08-27
+---
+
+# `syscall_window_nmi` reds when the host is somebody else's too
+
+One sighting, dev host, 2026-08-27, a 288-name `cargo test` run at 92 guests
+with a second worktree's suite on the same machine:
+
+```
+FAIL syscall_window_nmi: the storm never reported — is `syscall-window-nmi` on?
+  FAIL  syscall_window_nmi  (1505s)
+  ALONE syscall_window_nmi: GREEN
+```
+
+The isolated re-run in the same session took **5 s** and reported the storm in
+full — `3000 sent, 3000 taken, 43 in the window, 140 in Ring 3, 663 syscalls
+made under the storm`. The committed price is 6,825 ms, so the wide-run reading
+is a **220x wall stretch**: the guest was still working and had not finished,
+which is what its own message says when the storm line has not arrived yet.
+
+## Why this is filed rather than re-classified
+
+`ALONE: GREEN` is the harness naming a *hypothesis* — that the name's
+`Sched::Parallel` is wrong — and this file is not that claim.
+`tests/CLAUDE.md` is explicit: the harness suggests scheduling, the mechanism
+decides, and nothing here has measured a mechanism. What is measured is one
+red at 220x its price and one green at 1x.
+
+`cargo run -- --known-red syscall_window_nmi` answered **NOT ON THE LIST** when
+this was opened; `src/redlist.rs` now carries a row sourced here so the next
+agent who meets it is told whose it is.
+
+## What it is not
+
+Not the branch it was found on. That branch changed the syscall entry's
+displacement *spelling* (`const` operands for the same immediates, byte-identical
+machine code) and added two per-CPU stores per syscall for the panic path's
+`in_syscall` bracket. Neither moves a 6.8 s test to 1,505 s, and the same tip
+runs it green alone in 5 s.
+
+## What would settle it
+
+A rate. One sighting has no denominator, which is why there is no number in the
+row: the same suite run repeatedly on a host with and without a second
+worktree's build on it is what turns this into either a contention class the
+harness should schedule around or a defect in the storm's own pacing.
+`issues/build/parallel-tests-red-under-other-suites.md` is where the family
+lives, and this name is not on it.

issues/diagnostics/no-guest-can-change-the-display-mode.md

@@ -0,0 +1,38 @@
+---
+status: open
+kind: defect
+opened: 2026-08-27
+---
+
+# `SYS_GPU_SET_RESOLUTION`'s success path runs on no machine the suite boots
+
+Every guest `tests/common/qemu.rs` describes takes the UEFI GOP display path:
+no profile attaches a virtio-gpu device, and `Shape::vga` is `"std"` throughout.
+`GopGpu::set_resolution` answers `NotSupported` — GOP cannot change mode after
+boot services exit — so the whole of what a successful resize does is unexecuted
+by every test in this tree.
+
+## Measured
+
+Staged at `register_gpu` on 2026-08-27 and read off the boot log of
+`diskless_boot`:
+
+```
+md2 probe: the resize answered Err(NotSupported) and the registry says Some((2048, 2048))
+```
+
+## What that leaves uncovered
+
+Everything past the driver's refusal: the new framebuffer's allocation and the
+old one's release (`virtio_gpu.rs`), the panic console's detach-and-rearm window,
+the mode-change update of `device::set_framebuffer_info` and of the pointer's
+per-axis scale, and the compositor's own re-read of the returned `GpuInfo`. A
+defect in any of those is invisible here and visible on the owner's desktop,
+which is the one machine that runs virtio-gpu.
+
+## What would close it
+
+A profile that attaches `virtio-gpu-pci`, and a guest that claims the
+framebuffer, resizes, and compares what the call returned against what a second
+claim is told. It is a new registered name and a new profile, which is why it is
+filed rather than done beside the fix that needed it.

issues/kernel/a-double-fault-on-cpu-1-under-a-wide-suite.md

@@ -163,15 +163,17 @@ What survives of that class was audited here, in code:
   every redirection entry firmware left, so neither can deliver a vector at all.
   **Closed.**
 - every vector Intel names for 64-bit mode has a gate. **Closed by `9bd7a9e`.**
-- **the LAPIC's spurious-interrupt vector is `0xFF` and the IDT has no entry at
-  `0xFF`.** That is a defect on its own terms and is filed as
-  `issues/kernel/the-lapic-spurious-vector-has-no-gate.md`. **It is not
-  claimed as the cause of this sighting** — a spurious interrupt leaves nothing
-  behind, and what would deliver one on *this* configuration is itself
-  unestablished (that file has the reading). It is recorded here because
-  a `#DF` naming a live pid is precisely what it would look like, and because
-  closing it removes one of the three readings the next sighting has to be
-  weighed against.
+- the LAPIC's spurious-interrupt vector is `0xFF`, and the IDT had no entry at
+  `0xFF`. **Closed**: `arch/idt/spurious.rs` is that gate, and
+  `lapic_spurious_vector` raises the vector on purpose on every run. **It was
+  never claimed as the cause of this sighting** — a spurious interrupt leaves
+  nothing behind, and what would have delivered one on *this* configuration was
+  itself unestablished. It is recorded here because a `#DF` naming a live pid is
+  precisely what it would have looked like, and because closing it removes one
+  of the three readings the next sighting has to be weighed against.
+- **the other 235 `IdtEntry::EMPTY` slots are unchanged**, and each turns an
+  interrupt nobody expected into the same halt — filed as
+  `issues/kernel/an-unclaimed-vector-halts-the-machine-with-no-name.md`.
 
 ## Reproduction
 

issues/kernel/an-unclaimed-vector-halts-the-machine-with-no-name.md

@@ -0,0 +1,39 @@
+---
+status: open
+kind: defect
+opened: 2026-08-27
+---
+
+# 235 IDT entries are `P = 0`, and a delivery through one halts the machine saying nothing
+
+`kernel/src/arch/idt/mod.rs` fills the table from `idt_vectors!` and leaves
+every other slot `IdtEntry::EMPTY`, whose `type_attr` is `0`. A vector delivered
+through a gate with `P = 0` is not a fault the process takes: the CPU treats the
+missing gate as a second, contributory fault and escalates to `#DF`, which
+`double_fault_handler` answers with `halt_all_cpus`.
+
+## Measured, on this tree
+
+Taken as the negative control of the spurious-vector gate (2026-08-27): with
+that gate's row removed and the delivery still staged, the guest never reaches
+`===READY===` and the harness reports **`the console carried: nothing at all`**.
+Not a report, not a `DOUBLE FAULT` line, not a panic — a machine that stopped
+with no name on it, which is the whole of what this entry is about. With the row
+in place the same boot is green.
+
+## What would close it
+
+A single naked entry installed in every otherwise-unfilled slot, which counts
+the vector it took and reports it — the shape `arch/idt/spurious.rs` already
+has, minus the conditional EOI question, which it inherits: an unexpected
+vector may or may not be in service and the handler has to ask before it
+acknowledges.
+
+The reachable ones are not hypothetical. A stale MSI-X table entry left by a
+driver reconfiguration names a vector nothing gated; so does firmware that left
+an I/O APIC redirection entry pointing somewhere this kernel does not, which
+`ioapic::init` masks precisely because of it.
+
+**What it costs to get wrong**: a gate that absorbs a vector silently is a
+machine hiding an interrupt-routing defect, so the count and the report are the
+point, not the survival.