issues: the two reds main's guest lanes found stay until main's nightly meets their exits

Round 2 deleted both because #675 and #676 were to land in one batch with
this branch and close them. The owner has since ruled that #675 and #676
land on their own reviews, with a nightly run on main to confirm them, so
nothing closes these two by this branch's landing. They are restored as
round 2 found them, at 90a989e^: when this branch lands, each goes only if
main's nightly has met its exit, and otherwise stays, corrected.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016t9wjdQkB8SH7bmfUoiy6L

Author: Japabu

issues/kernel/every-aarch64-guest-dies-at-the-kernels-entry-on-cis-firmware.md

@@ -0,0 +1,37 @@
+---
+status: open
+kind: defect
+opened: 2026-10-01
+---
+
+# Every AArch64 guest dies at the kernel's entry on CI's firmware
+
+All sixteen `virt_*` tests red in CI. Each boot's console ends the same way:
+`Loader log: the kernel handoff begins`, then the firmware's
+`Synchronous Exception at 0x00000000BC33EB20`. The PC differs per kernel build,
+but always falls inside the kernel image the loader placed at `0xbc200000`. That
+happens at EL1 entry (`Profile::Virt`) and at EL2 entry (`VirtEl2`), on one CPU
+and on eight. The kernel prints nothing first, so the tests time out waiting for
+their first marker.
+
+**Evidence**, identical in two runs on toolchain
+`toolchain-linux-x86_64-48dd24f826263d6c`:
+- Main's nightly `guest` lane at `06788146b`, run 36843762360, job 110374194368.
+- PR #671's `guest` check, on its merge onto `59052827f`, run 36863809437, job
+  110375742604.
+
+Both ran QEMU 11.1.1 under TCG `-cpu max` on an AMD EPYC 9V45 with 4 cores. The
+firmware was Debian's `AAVMF_CODE.no-secboot.fd`, "version 2026.05-2". Both
+logged `test result: FAILED. 4 passed, 17 failed`. The other red is
+`issues/kernel/the-nested-nmi-report-interleaves-with-another-cpus-console-line.md`.
+
+The same sixteen tests pass on the dev host, in a whole-suite run of #670's
+branch (`test result: ok. 21 passed`). That host ran QEMU 11.1.1 from
+Homebrew, under the same TCG `-cpu max` for `VirtEl2`. Two parts of the
+instrument differ:
+- The firmware: the dev host runs QEMU's bundled `edk2-stable202408-prebuilt.qemu.org`.
+- The toolchain: the dev host builds its own, and CI installs the published release.
+
+`.github/qemu-version` pins neither of the two.
+
+**Exit:** the sixteen `virt_*` tests are green in CI's `guest` check.

issues/kernel/the-nested-nmi-report-interleaves-with-another-cpus-console-line.md

@@ -0,0 +1,28 @@
+---
+status: open
+kind: defect
+opened: 2026-10-01
+---
+
+# The nested-NMI report interleaves with another CPU's console line
+
+`nested_nmi` (`kernel/src/arch/x86_64/idt/nmi.rs`) writes its report through
+`serial::panic_raw`, which takes no lock. When cpu1 is writing its own record at
+the same moment, the two lines interleave byte by byte on the 16550. The cpu1
+line was `[kernel 0.385 cpu1] CPU 1: joining scheduler`, and the 16550 carried:
+
+    [[kenrnmel i0.38]5  cpNu1E] CSPUT 1E: Djo inNiMngI s choednule r
+
+`NESTED NMI` is never whole on the console, so `nested_nmi_is_loud` times out
+waiting for it, and the machine halts with its report unreadable.
+
+**Evidence:** red under KVM in two runs, with byte-identical interleaving:
+- Main's nightly `guest` lane at `06788146b`, run 36843762360, job 110374194368.
+- PR #671's `guest` check, on its merge onto `59052827f`, run 36863809437, job
+  110375742604.
+
+It is green under TCG: on the dev host in a whole-suite run of #670's branch,
+and on a runner in main's nightly `tcg` lane at `06788146b` (job 110374194382).
+
+**Exit:** `nested_nmi_is_loud` is green in CI's KVM `guest` check, and a report
+written while another CPU is writing a record reads whole.