xenia-rs/audit-runs/phase-c24-post-vdswap-branch/investigation.md

# Phase C+24 — post-VdSwap KeAcquireSpinLockAtRaisedIrql divergence

**Date:** 2026-05-26
**Mode:** READ-only investigation. NO engine change, NO diff-tool change, NO test change.
**Status:** ESCALATED (scheduler-determinism deferred class).

## TL;DR

The post-C+23 first divergence at canary `tid=6` ↔ ours `tid=1` idx
105,286 is **NOT a control-flow branch chosen by guest state**. It is a
**scheduling-cadence divergence**: ours fires the first VSYNC graphics
interrupt callback EARLIER than canary, inserting 6 extra events
(`KeAcquireSpinLockAtRaisedIrql` + `KeReleaseSpinLockFromRaisedIrql`,
×3 events each) into ours's tid=1 stream between `VdSwap.return` and
`VdGetCurrentDisplayGamma`. Canary fires the SAME interrupt path with
the SAME r3=0 (VSYNC) argument, just at a different wall-clock /
trajectory point. Per tripstone #5 (escalation when divergence
requires scheduler-determinism resolution), C+24 lands NO change. Main
matched-prefix stays at 105,286.

## Event-context capture (Step 1)

### Pre-context (5 matched events)

Both engines bit-identical:

```
import.call VdGetSystemCommandBuffer
kernel.call VdGetSystemCommandBuffer
kernel.return VdGetSystemCommandBuffer
import.call VdSwap
kernel.call VdSwap
kernel.return VdSwap
```

### Divergent event

```
canary[105293]: import.call VdGetCurrentDisplayGamma            (ord 441)
ours  [105286]: import.call KeAcquireSpinLockAtRaisedIrql       (ord 77)
```

### Post-divergence flow (ours)

```
ours[105286-105288]: import/call/return KeAcquireSpinLockAtRaisedIrql
ours[105289-105291]: import/call/return KeReleaseSpinLockFromRaisedIrql
ours[105292-105294]: import/call/return VdGetCurrentDisplayGamma   ← realigns with canary[105293-105295]
```

### Streams re-converge at offset +6 in ours

After the 6 extra ours events, both streams call **the same** import
sequence: `VdGetCurrentDisplayGamma → VdSetDisplayMode → VdGetCurrentDisplayInformation
→ VdQueryVideoFlags (returns 3, per C+23) → VdQueryVideoMode → ...`. So
the 6 events are an **inserted block in ours**, not a permanent
trajectory split.

But **secondary divergences appear ~24 events later**: ours's
post-block stream diverges from canary again with
`canary: MmFreePhysicalMemory` vs `ours: KeEnterCriticalRegion` at
offset +24. This pattern of "absorb-realign-diverge" repeats; a simple
6-event absorber would expose a chain of downstream divergences, each
needing separate analysis.

## LR localisation (Step 2)

Ran ours with `--branch-probe=0x8284e1ec` (the KeAcquire import thunk).
**First fire** at `cycle=5584980, lr=0x824bea14, r3=0x42453918` — same
cycle as the divergent event's `guest_cycle=5584999`. Caller PC =
`lr - 4 = 0x824bea10`, inside function **`sub_824be9a0`**.

Cross-reference in `sylpheed.db`: `sub_824be9a0` has **zero `bl`
callers** in the static disasm — it's NOT called directly by guest
code. It IS the **graphics interrupt callback** armed via
`VdSetGraphicsInterruptCallback(0x824be9a0, ctx)` per
`crates/xenia-kernel/src/exports.rs:4101` and confirmed in 10+ audit
logs.

## Function body of `sub_824be9a0` (the guest ISR)

```ppc
0x824be9a0  mfspr   r12, LR
0x824be9a4  bl      __savegprlr_29
0x824be9a8  stwu    r1, -128(r1)
0x824be9ac  or      r31, r4, r4              ; r4 = user_data (ISR arg2)
0x824be9b0  cmpli   cr6, 0, r3, 0x1          ; r3 = ISR source (arg1)
0x824be9b4  bc      eq, 0x824BEA30           ; r3 == 1 → counter path
;   --- r3 != 1 (i.e. r3 == 0, VSYNC) path: spinlock + bit-clear ---
0x824be9b8  lwz     r10, 10772(r31)
   ...                                      ; load dispatch fn pointer
0x824be9f0  mtspr   CTR, r30                  ; first guest-handler dispatch
0x824be9f4  bcctrl
0x824be9f8  lbz     r10, 268(r13)             ; per-CPU IRQL
0x824bea08  or      r3, r30, r30
0x824bea0c  slw     r29, r11, r10
0x824bea10  bl      0x8284E1EC                ; KeAcquireSpinLockAtRaisedIrql
0x824bea14  lwz     r11, 0(r31)
   ...                                      ; clear pending-IRQ bit
0x824bea28  bl      0x8284E1DC                ; KeReleaseSpinLockFromRaisedIrql
0x824bea2c  b       0x824BEAAC                ; → epilogue
;   --- r3 == 1 path: counter / no spinlock ---
0x824bea30  cmpli   cr6, 0, r3, 0x0
0x824bea34  bc      eq, 0x824BEAAC            ; r3==0 already handled above
0x824bea38  addis   r11, r0, 0x7FC8           ; load D1MODE_V_COUNTER MMIO
0x824bea3c  lwz     r11, 25924(r11)
   ...                                      ; counter update + optional callback
0x824beaa4  mtspr   CTR, r11
0x824beaa8  bcctrl
0x824beaac  epilogue
```

## Cross-reference to canary's source

`xenia-canary/src/xenia/kernel/xboxkrnl/xboxkrnl_video.cc:303-310`:

```cpp
void VdSetGraphicsInterruptCallback_entry(function_t callback,
                                          lpvoid_t user_data) {
  // callback takes 2 params
  // r3 = bool 0/1 - 0 is normal interrupt, 1 is some acquire/lock mumble
  // r4 = user_data (r4 of VdSetGraphicsInterruptCallback)
  ...
}
```

So per canary's own comments:
- `r3=0` (VSYNC / "normal interrupt") → guest takes the spinlock path
- `r3=1` ("acquire/lock mumble", presumably the CP-interrupt) → guest takes the counter path

In **both engines**, ours and canary, when the first VSYNC fires after
VdSwap, the callback is invoked with `r3=0` and the spinlock path
executes. **The only difference is timing.**

## Per-engine VSYNC dispatch model

### Ours
- `kernel.interrupts.tick_vsync_instr(instruction_count)` accumulates
  instructions; fires VSYNC when `vsync_accumulator >= 150_000`.
- `try_inject_graphics_interrupt` runs every scheduler round; injects
  the queued VSYNC into the first Ready (else Blocked) HW thread.
- Lockstep / diff-harness path uses `tick_vsync_instr` (not wall-clock).
- Net effect: ours fires VSYNC ~every 150k guest instructions ≈ every
  scheduler round once instruction count grows; the FIRST VSYNC is
  delivered right after VdSwap returns because that's when tid=1
  becomes Ready and `is_in_callback==false`.

### Canary
- A dedicated host thread `frame_limiter_worker_thread_`
  (`graphics_system.cc:148-237`) calls `MarkVblank()` →
  `DispatchInterruptCallback(0, 2)` → `EmulateCPInterruptDPC(callback,
  data, source=0, cpu=2)`.
- Wall-clock paced via `Clock::QueryGuestTickCount()` vs
  `vsync_duration_d = 16.67 ms` (60 Hz).
- First MarkVblank fires after at least 16.67 ms wall-clock from
  frame-limiter thread creation.
- The callback runs on whichever XThread is current at dispatch time
  (not tid-locked).

## Empirical counts (sanity)

| engine | total KeAcquire calls | first KeAcquire idx | first KeAcquire host_ns |
|---|---|---|---|
| canary | 16,000 | tid=6 idx 106,805 | 1,731,840,900 (~1.73 s) |
| ours   | 32     | tid=1 idx 105,286 | 1,437,632,028 (~1.44 s) |

Canary's first VSYNC interrupt fires ~80 ms after canary idx 105,286
(host wall-clock from canary log) — i.e. canary's tid=6 has time to
make ~1,500 more events before the first interrupt arrives. Ours's
first VSYNC arrives RIGHT at idx 105,286.

The total-count gap (16,000 vs 32) is largely a runtime-window
artifact: canary ran 90 s of wall-clock; ours ran ~1.5 s of guest
time before wedging at the C+22 cap (downstream). Within ours's
runtime window, the *rate* of vsync delivery is similar to canary's;
the issue is the OFFSET of the first delivery.

## Class triage

| class | description | applies? |
|---|---|---|
| A | Different LR → different caller, real control-flow branch | NO — LR identical, function identical, both engines take the SAME `r3=0` path |
| B | Same LR / computed call with different fn pointer | NO — bl to fixed import thunk |
| C | Game-state-dependent (state polled, branch taken) | NO — the branch in `sub_824be9a0` is on the ISR's `r3` arg, which is `0` (VSYNC) in BOTH engines |
| D | Phase A coverage gap | NO — events are accurately captured |

**Actual class: scheduler-cadence divergence.** The 6 events are not
in the "main thread's compute" stream; they're in an
**interrupt-context insertion** that ours delivers at a different
wall-clock moment than canary.

## Why this is NOT a candidate for an engine-side fix

1. **Tripstone #5**: investigation reveals scheduler-determinism
   issue → STOP and report.
2. **MEMORY.md** explicitly lists "scheduler determinism" in the
   deferred bucket (review_a_boot_state_2026_05_21 entry: "Deferred:
   audio/HID/XAM/scheduler-determinism/diff-tool-canonicalization").
3. The two engines have **fundamentally different VSYNC clock
   sources**: ours's `tick_vsync_instr` uses guest-instruction counts,
   canary's `frame_limiter_worker_thread_` uses host wall-clock. To
   align ours's first-vsync moment with canary's would require either:
   - Adopting wall-clock pacing for the lockstep diff harness
     (invalidates 23 phases of digest stability, per Phase D
     forensics' explicit warning), or
   - Calibrating the instruction-count threshold per cold run
     (non-deterministic, defeats the diff-harness's purpose).
4. The natural-progression goal is to fix REAL game-logic bugs.
   Forcing this specific VSYNC moment to align would mask the actual
   scheduler-determinism problem rather than resolve it.

## Why this is NOT a candidate for a diff-tool absorber (at this layer)

A naïve 6-event absorber (`absorb KeAcquire + KeRelease pair if
canary doesn't have one at the same position`) would advance the
matched-prefix past idx 105,286, but **only by 24 events** before
the next, different divergence: canary's `MmFreePhysicalMemory` vs
ours's `KeEnterCriticalRegion` at the +24 offset. The chain
`absorb-realign-diverge` repeats. Each downstream divergence will
need its own analysis. Adding an absorber here without first
characterizing the downstream divergences risks:

1. **Reading-error #23 crossover** (band-aid masks real divergence).
2. **Reading-error #32 inflation** (timing-window absorbers should be
   narrow; this one would fire on every VSYNC-driven cadence offset).
3. **Spurious main-prefix advancement** that hides multiple genuine
   issues downstream.

The Phase D D-extension absorber (nested-CS-cleanup) was a
**narrow, exhaustively-characterized** band-aid for a specific cap;
this VSYNC-cadence shape lacks that characterization.

## Recommended next action

ESCALATE to a dedicated scheduler-determinism methodology pivot
(reading-error #32 / phase-c23-scheduler-determinism-plan refresh).
Options:

1. **Adopt wall-clock vsync in lockstep** under a feature flag, accept
   non-determinism in the diff harness, treat matched-prefix as a
   noisy metric — re-baseline all Phase C+nn caps.
2. **Pin first-VSYNC delivery** to a guest-instruction landmark common
   to both engines (e.g. first `kernel.return VdSwap` on
   `VdSetGraphicsInterruptCallback`'s registered callback). Requires
   engine-side coordination + canary patch.
3. **Build a VSYNC-cadence-aware absorber** that absorbs
   interrupt-callback-induced event sequences on BOTH sides up to
   alignment landmarks. Requires characterizing the full set of
   guest-ISR shapes — `sub_824be9a0` is one of N callback bodies the
   absorber must recognize.

All three options are out-of-scope for C+24 per the original task's
escalation rule.

## Files inspected (read-only)

- `xenia-rs/audit-runs/phase-c23-VdQueryVideoFlags/diff-jitter-1.md`
  (predecessor diff report)
- `xenia-rs/audit-runs/phase-a-diff-harness/schema-v1.md` (schema /
  absorber inventory; v1.7)
- `xenia-canary/src/xenia/kernel/xboxkrnl/xboxkrnl_video.cc:303-310,
  438-523` (`VdSetGraphicsInterruptCallback_entry`, `VdSwap_entry`)
- `xenia-canary/src/xenia/gpu/graphics_system.cc:148-237, 352-374`
  (frame_limiter_worker, MarkVblank, DispatchInterruptCallback)
- `xenia-canary/src/xenia/kernel/kernel_state.cc:1365-1405`
  (`EmulateCPInterruptDPC`)
- `xenia-rs/crates/xenia-kernel/src/interrupts.rs` (full file —
  InterruptState, tick_vsync_instr, tick_vsync_wallclock)
- `xenia-rs/crates/xenia-app/src/main.rs:2440-2474, 3700-3812`
  (vsync ticker + injector)
- `xenia-rs/crates/xenia-kernel/src/exports.rs:4086-4108`
  (`vd_set_graphics_interrupt_callback`)
- `xenia-rs/sylpheed.db` (xrefs, instructions on
  `sub_824be9a0`/`sub_824ce4d0`/`sub_824cea80`)

## Files touched (changed)

NONE. C+24 is read-only investigation.

## Test suite

xenia-kernel: **226 PASS** (unchanged from C+23 baseline). No code
edits, no test additions.

## Phase B `image_canonical_sha256`

Pinned hash `ea8d160e…` UNCHANGED — no XEX loader changes.

## Cascade

| | predicted | actual |
|---|---|---|
| A capture event context | 95% | **PASS** |
| B classify (A/B/C/D) | 75% | **PASS** (none of A/B/C/D — fifth class: scheduler-cadence) |
| C identify root cause | 60% | **PASS** (ours vsync_instr_period mistimed vs canary wall-clock frame-limiter) |
| D land fix or clean escalation | 65% | **PASS — clean escalation** |
| E main > 105,286 | 55% | **N/A — no engine change** |

## Tripstones honored

1. Reading-error #28 — verified canary semantics by reading
   `xboxkrnl_video.cc:303-310` directly; the r3=0/1 contract is
   documented in canary's own source comments. NOT assumed.
2. Reading-error #23 — explicitly chose NOT to land a downstream-
   risky absorber/fix. Main matched-prefix stays at 105,286.
3. Reading-error #31 — no fresh canary run made; used the C+23
   archived jitter set. State of `cache/` + `cache_host/` unchanged.
4. Reading-error #32 — the cause IS scheduling-jitter on the
   interrupt-cadence axis. Confirmed by the empirical
   first-acquire-host-ns table above.
5. Escalation rule — TRIGGERED. Root cause requires
   scheduler-determinism methodology pivot, deferred per MEMORY.md.
6. `--mute=true` — N/A this session (one `xrs-c23 exec` probe run
   for `--branch-probe` capture; no canary run).