panic.txt — harness v1 incident (NOT a finding of this audit)
=============================================================

After kldload of icuintro v1 (which called lwkt_setcpu_self(globaldata_find(0))
from the kldload process thread to "pin to CPU0"), the guest completed all
harness phases successfully and then panicked on the NEXT syscall of the
migrated thread:

  D0..P6 all printed correctly (P4 skipped in v1: MachIntrABI != ICU)
  panic with 1 spinlocks held
  panic: assertion "lp->lwp_qcpu == dd->cpuid" failed in dfly_acquire_curproc at /usr/src/sys/kern/usched_dfly.c:453
  cpuid = 0
  Trace beginning at frame 0xfffff801187bf8d8
  dfly_acquire_curproc() at dfly_acquire_curproc+0x979 0xffffffff8066ea09
  dfly_acquire_curproc() at dfly_acquire_curproc+0x979 0xffffffff8066ea09
  syscall2() at syscall2+0x288 0xffffffff80bd6b78
  Debugger("panic")
  CPU0 stopping CPUs: 0x0000003e
  Stopped at Debugger+0x7c: movb $0,0xbdaf09(%rip)
  db>

Root cause: HARNESS bug. lwkt_setcpu_self() is an internal LWKT primitive;
calling it from an arbitrary userspace process thread migrates the thread
behind usched_dfly's back and violates its lwp_qcpu bookkeeping, tripping the
scheduler's own sanity assertion on the following syscall. It is reachable
only from root-loaded kernel code (no unprivileged path), so it is not a
security finding of the kernel under audit; v2 of the harness removed the
pinning and ran clean (run.log) on a freshly reset guest.

Also visible in the v1 serial capture (before the panic) — first live
confirmation run of D0-D2/P2/P3/P5/P6, values identical to run.log:
  D0: ncpu=6 mycpuid=0 MachIntrABI.type=2 (MACHINTR_ICU=1)
  D1: icu_imen(shadow)=fffb hw_imr=fffb coherent=YES
  D2: ELCR=0c00
  P3: (uint8_t)~(1 << -1) = 0xff
  P2: irq0 mask-cycle ... persist=YES
  P5: ICU2 ICW cycle, ELCR_HI 0c -> 0c (persists across ICW)
  P6: alive, ticks delta=200 ... coherent=YES