xenia-rs/audit-runs/phase-xaudio-resume/escalation.md

Phase XAudio-Resume — ESCALATION (case IV)

Date: 2026-05-19 Outcome: Resume mechanism is correctly implemented. The 60% missing event volume is gated on a DOWNSTREAM application-level spin-poll, not on the resume itself. No engine change landed.

Canary's resume mechanism (Step 1+2)

For each suspended XAudio worker (entry_pc=0x824D2878 aff=16 → tid=14; entry_pc=0x824D2940 aff=32 → tid=15), canary tid=6 (main) emits an identical 6-call sequence immediately after ExCreateThread:

canary tid=6 idx=106750..106766  (host_ns 1726.0..1726.2 ms)
  106750 import.call ExCreateThread
  106751 kernel.call ExCreateThread
  106752 handle.create        (raw_handle 0x???????? — tid=14 handle)
  106753 thread.create        (entry_pc=0x824d2878, suspended=true)
  106754 kernel.return ExCreateThread
  106755 import.call ObReferenceObjectByHandle
  106756 kernel.call ObReferenceObjectByHandle
  106757 kernel.return ObReferenceObjectByHandle
  106758 import.call KeSetBasePriorityThread
  106759 kernel.call KeSetBasePriorityThread
  106760 kernel.return KeSetBasePriorityThread
  106761 import.call KeResumeThread            ← RESUME (xboxkrnl ord 146)
  106762 kernel.call KeResumeThread
  106763 kernel.return KeResumeThread
  106764 import.call ObDereferenceObject
  106765 kernel.call ObDereferenceObject
  106766 kernel.return ObDereferenceObject

Block repeats verbatim at idx 106767-106783 for entry_pc=0x824D2940. Containing function is XAudioRegisterRenderDriverClient (visible at idx 106817).

Ours's behavior at the matched site (Step 3)

Cold ours (-n 500M, --halt-on-deadlock, fresh cache wipe), checked against /tmp/ours-xaudio.jsonl (121,569 events captured before halt):

ours tid=1 idx=106756..106786   (host_ns 1626 ms — boot is ~100 ms ahead of canary)
  106756 import.call ExCreateThread
  106757 kernel.call ExCreateThread
  106758 handle.create
  106759 thread.create     (entry_pc=0x824d2878, suspended=true) ← matches canary
  106760 kernel.return ExCreateThread
  ...
  106767 import.call KeResumeThread             ← RESUME fires
  106768 kernel.call KeResumeThread
  106769 kernel.return KeResumeThread
  ...
  106776 thread.create     (entry_pc=0x824d2940, suspended=true) ← matches canary
  ...
  106784 import.call KeResumeThread             ← second RESUME fires
  106785 kernel.call KeResumeThread
  106786 kernel.return KeResumeThread

ours's per-tid first-events (cold) for the spawned children:

tid=9  (=canary tid=14, entry 0x824d2878): 77 events, idx 0..76 identical to canary tid=14
tid=10 (=canary tid=15, entry 0x824d2940): 17 events, idx 0..16 identical to canary tid=15

Ours's tid=9 / tid=10 EXECUTE the canary-matching XAudio init sequence: KeWaitForSingleObject (with immediate signal) → spinlock/IRQL cycle → XAudioGetVoiceCategoryVolumeChangeMask → KeReleaseSemaphore → more IRQL cycles. Then halt.

Halt-on-deadlock diagnostic shows tids 9 and 10 in state Ready at pc=0x824d1404 lr=0x824d22b4 — they are NOT blocked on a missing kernel API, they are inside a guest-side spin-poll loop:

0x824d1400:  beqlr   cr6                          ; return if poll succeeded
0x824d1404:  cmpd    cr6, r10, r11                ; r10 vs r11
0x824d1408:  beq     cr6, 0x824D1420              ; ok-branch
0x824d140c:  mr      r31, r31                     ; nop (yield hint)
0x824d1410:  ld      r11, 0(r4)                   ; reload [r4]
0x824d1414:  cmpdi   cr6, r11, 0
0x824d1418:  bne     cr6, 0x824D1404              ; if nonzero, loop
0x824d141c:  blr

r4 = r31+356 (caller pushes addi r4, r31, 356 at 0x824d22a8). The threads are spin-polling guest memory at [r31+356] waiting for it to reach 0.

Classification: case IV (not I / II / III)

The plan's original classification anticipated:

• (I) ours doesn't reach the spawn LR ← refuted: spawn fires at idx 106756/106773
• (II) ours reaches spawn but no resume ← refuted: KeResumeThread fires at idx 106768/106785
• (III) ours's NtResumeThread is misimplemented ← refuted: resume_ref() correctly clears Blocked(BlockReason::Suspended) → Ready; halt diagnostic confirms post-resume Ready state and identical first-77/17 events to canary

Actual classification (IV): Resume succeeds; XAudio threads start running and execute their init sequence verbatim against canary; then enter a guest-side application spin-poll on [r31+356] that never resolves in ours. The producer of the 0-write to that location is part of canary's audio/GPU host bridge chain that AUDIT-048 only partially restored (cascades A/B/D landed; cascade C — XAudioSubmitRenderDriverFrame — remained 0 per that audit's own assessment).

Why the 60% volume claim doesn't follow from a resume-only fix

Phase NonMatch's "60% missing event volume" attribution to XAudio assumed the threads simply weren't running. They ARE running — they emit identical first events, get scheduled, and reach the spin loop. The volume bottleneck is the post-init steady-state pump: canary's 6.15 M tid=14 events come from 26,126 repeated iterations of the XAudioGetVoiceCategoryVolumeChangeMask / KeReleaseSemaphore / IRQL-cycle loop, each iteration gated on the host bridge clearing the [r31+356] flag. With the flag stuck non-zero in ours, the loop never re-enters; only the single first iteration (idx 0-76) ever executes. No quantum of resume-side change is going to unstick this.

Out-of-scope for this session

Per session authorization, fixing the host-bridge memory-write that clears [r31+356] requires touching xenia-apu/xenia-gpu host code, which is explicitly forbidden ("the host bridge is separate"). Therefore no engine change lands in this session.

Progression metric (re-validation gate, baseline-only)

Not re-measured for a change — there was no change. Pre-existing baseline remains the C+23+absorber state (23cf4c4cbf61a577caa4118ab2308ba6 / ba5b5e07… depending on Phase D stage). swaps and draws unchanged. Per-chain matched-prefixes from MEMORY.md remain:

• main tid=6→1: 105,046 (with Phase D D-extension absorber)
• sister chains 11/32/4/41/16: preserved

Recommended next attack target

The remaining XAudio gate is AUDIT-048 cascade C: producer of the [r31+356]=0 write. This is the part of the audio host-bridge chain that did NOT land in AUDIT-048. It likely involves:

1. XAudioSubmitRenderDriverFrame host-side callback firing the buffer-complete event with a side effect that decrements/clears a counter at offset 356 of the XAudio client struct.
2. KeReleaseSemaphore on a paired semaphore that produces the host-side buffer-complete notification.

A targeted re-attack would:

1. Read xenia-canary's apu/audio_system.cc + apu/xma_decoder.cc to find the host-side write that clears r31+356 (likely an XAUDIO_CLIENT_STATE struct field).
2. Mirror it in xenia-rs's xaudio.rs / audio worker context.
3. Re-validate the cold cycle. swaps may move 1→2 if the audio pump reaches the renderer fence; draws likely remain 0 (audio ≠ renderer per AUDIT-048).

That work is the AUDIT-048-cascade-C completion task, NOT the resume gate. It's the natural sister of the deferred sub_825070F0 main-gate Path P.

Per-chain delta (no change this session)

chain	pre	post	delta
tid=6→1 main	105,046	105,046	0
tid=11→11	preserved	preserved	0
tid=14→9 XAudio	41	41	0
tid=15→10 XAudio	16	16	0
tid=4→4	preserved	preserved	0
tid=16→16	preserved	preserved	0

Artifacts

• tid6_window.json — canary tid=6 events idx 106700..108200 around the XAudio spawn burst
• tid14_first.json / tid15_first.json — canary tid=14/15 first 120 events
• extract_window.py — extraction script
• escalation.md — this file