xenia-rs/audit-runs/iterate-2H-physical-heap-vA/writer-report.md

Iterate 2.H — Physical heap vA0000000 bucket (writer report)

Date: 2026-05-28. LOC delta: engine +99 / -3 (2 files), canary 0. Tests: xenia-kernel 227 PASS (was 226 — +1 new test), xenia-memory 19 PASS. Zero regressions.

Headline

PRIMARY-GATE-PASS-NO-CASCADE. All three diverging ctx_ptr columns now land in the 0xAxxxxxxx-0xBxxxxxxx canary vA0000000 heap range (was 0x4xxxxxxx). The structural address-space-bucket divergence is closed. The secondary cascade (missing producer LRs, canary tids 15/27/28 worker fan-out, tid=1 wedge) is unchanged — the run produces a bit-identical event count (118,149) and the same set of 10 spawned thread entry_pcs as the iterate-2F baseline. Allocation-bucket was not the upstream cause of the worker-fan-out absence.

Mode detected

Boot trajectory captured via exec -n 50000000 --quiet --phase-a-event-log … (same invocation as iterate-2F-vdswap-drain-fix/ours-cold.jsonl). 50M-instruction budget completes in <1 s wallclock and ours wedges at the same set of guest PCs.

Patch

Files

• xenia-rs/crates/xenia-kernel/src/state.rs

  • +12 LOC: new field physical_heap_cursor: AtomicU32 on KernelState with docstring tying it to canary memory.cc:269-271.
  • +3 LOC: init in with_gpu() to 0xC000_0000 (top-exclusive frontier of the 0xA0000000-0xBFFFFFFF bucket).
  • +37 LOC: new method physical_heap_alloc(&self, size, mem) -> Option<u32> — 64KB-aligned, top-down, CAS-loop bump allocator with 0xA000_0000 floor check; on success delegates to mem.alloc(base, size, READ|WRITE).
  • +22 LOC: smoke test physical_heap_alloc_descends_in_va_range proving 10 consecutive 0x1234-byte allocs are descending, range-bound, and 64KB-aligned.

• xenia-rs/crates/xenia-kernel/src/exports.rs

  • +18 / -3 LOC in mm_allocate_physical_memory_ex: read protect_bits from r5; route X_MEM_LARGE_PAGES (0x20000000) requests to the new physical_heap_alloc, fall through to existing heap_alloc for non-large-page (4KB / 16MB-page) cases. Mirrors canary xboxkrnl_memory.cc:436-455 flag→heap-bucket dispatch.

Total git diff: 2 files, +99 insertions / -3 deletions = 96 net LOC.

Within the 80-150 target band, well under the 200 hard cap.

Out-of-scope (per prompt SCOPE GUARDS — deferred to follow-up)

• vC0000000 (16MB-page bucket) and vE0000000 (4KB bucket) — NOT wired. Non-large-page MmAllocatePhysicalMemoryEx calls still fall through to the legacy heap_alloc at 0x4000_0000 (preserves prior behavior).
• mm_get_physical_address masking — untouched.
• MmFreePhysicalMemory — untouched (no free-list yet; minimal cursor bump-allocator, per prompt guidance).

Primary gate result

thread.create events with ctx_ptr not in static-allocated 0x828Fxxxx region (the diverging entries called out by the prompt):

entry_pc	canary ctx_ptr	2.F (pre-fix) ctx_ptr	2.H ctx_ptr	gate
0x824cd458	0xbe56bb3c	0x42453b3c	0xbe8cbb3c	PASS (in 0xAxxx-0xBxxx, low-3-bytes 0x8cbb3c vs canary 0x56bb3c, low-2-bytes 0xbb3c exact-match)
0x822f1ee0	0xbce24a40	0x40d0ca40	0xbd184a40	PASS (in 0xAxxx-0xBxxx, low-2-bytes 0x4a40 exact-match)
0x821748f0	0xbc365620	0x4024d640	0xbc6c5580	PASS (in 0xAxxx-0xBxxx, high-byte 0xbc exact-match)

The four entries the prompt called "static — already passes" still match exactly (0x828f3d08, 0x828f4838, 0x828f3b68, 0x828f3b08).

Notes:

• Exact bit-for-bit ctx_ptr parity vs canary is not expected (and is not required by the gate) because top-down allocation order depends on the specific sequence of intervening MmAllocatePhysicalMemoryEx calls from other engine paths (XEX header preload, kernel objects, audio voice structs, etc.). The 2.H allocator services every X_MEM_LARGE_PAGES request, not just the seven on this table — so the cursor lands at offsets reflecting cumulative bytes-out before each thread.create.
• The low-bytes match (0xbb3c / 0x4a40) is a strong structural signal: ours and canary now produce the same per-instance struct offsets within their respective heap pages, which means the MmAllocatePhysicalMemoryEx callers are requesting the same sizes in the same sequence. Only the heap top-of-cursor differs.
• The two ctx_ptr=0x00000000 entries (0x824d2878 / 0x824d2940 audio worker entries) are by-design (suspended audio workers spawn with null context); unchanged.

Determinism check (gate gate): two consecutive 2.H runs produce identical thread.create ctx_ptr columns (table above is bit-stable across runs). Engine count: 118,149 events, ditto. guest_cycle drift ~120 cycles is pre-existing scheduler-interleaving non-determinism (documented in scheduler-determinism-plan), not introduced by 2.H.

Secondary cascade gate results

Per prompt: cascade gates are not required for the fix to land, but status matters.

(b) Missing (op, lr) tuples (iterate-2D method)

Not re-run. Would require fresh --lr-trace of the IAT thunks (0x8284DDDC,0x8284E49C,0x8284DF5C,0x8284E07C) which is a separate capture mode. The 2.D diff script analyzes that trace and the canary audit-69/70 traces; the new ours-cold.jsonl from phase-a-event-log doesn't feed that pipeline directly. Indirect evidence: the boot trajectory hits 118,149 events identical to 2.F at the kernel-call granularity (same total, same thread set, same wedge location at guest_cycle=450,294 on tid=5 — see "tid=1 wedge" below). High confidence the 2.D fire-pattern result is UNCHANGED. Gate (b): expected UNCHANGED (28/28).

(c) Canary tids 15/27/28 ours analogs

Spawned thread entry_pc set (10 entries) is bit-identical to 2.F baseline:

0x821748f0, 0x82178950, 0x82181830, 0x822f1ee0, 0x82450a28,
0x82457ef0, 0x8245a5d0, 0x824cd458, 0x824d2878, 0x824d2940

The sub_825070F0 post-VdSwap worker fan-out (which would spawn the analogs for canary tids 15/27/28) is still absent. Gate (c): FAIL (0 → 0).

(d) Producer-rate at LR 0x824AB168

Not directly measured (would need --lr-trace=0x824AB158 re-run). Indirect indicator: identical event count + identical thread set → producer-call sequence is structurally unchanged. Gate (d): expected UNCHANGED (~9.97% → ~9.97%).

(e) tid=1 wedge timestamp

Last 3 events on the 2.H run terminate with tid=5 waiting on a single handle (semantic_id d1cc2ba936cfd448) at guest_cycle=450,294 / host_ns ≈ 797,232,750. 2.F's terminal block was tid=1 + tid=13 at the same wedge PC 0x824ac578 per its writer-report; identical event-count + identical thread set implies the same wedge geometry. Wallclock difference is pre-existing (2.F removed the 900ms VdSwap drain). Gate (e): NEUTRAL — wedge presence unchanged; ctx_ptr is now in the right bucket but the wedge is downstream of allocation.

Cascade roll-up

gate	description	result
Patch LOC ≤ 200	hard cap	PASS (96 LOC net)
Patch LOC 80-150	target band	PASS (96 LOC net)
Build clean	warnings only, no errors	PASS
xenia-kernel tests	no regression, +1 new	PASS (227/227, was 226)
xenia-memory tests	no regression	PASS (19/19)
Determinism (ctx_ptr)	2 runs bit-stable on diverging entries	PASS
PRIMARY: ctx_ptr in 0xAxxx-0xBxxx range	3/3 diverging entries	PASS
(b) missing (op,lr) tuples drop from 28	not re-measured; expected unchanged	n/a
(c) ours analogs for canary tids 15/27/28	0 → 0	FAIL
(d) producer-rate at 0x824AB168 ≥10%	not re-measured; expected unchanged	n/a
(e) tid=1 wedge moved/absent	same wedge geometry	NEUTRAL

Outcome class: PRIMARY-GATE-PASS-NO-CASCADE. The structural address-space-bucket bug is closed. The downstream cascade (worker fan-out, producer rate, wedge) is unaffected.

Why the cascade did not follow

The 2.G report (per memory index) framed the 0xBCE25640 ctx-state installer chain as the next blocker once vA0000000 was mapped. 2.H maps the bucket but does NOT address what writes the vtable at [ctx+44] to point at 0x8200A1E8 / what game-side path leads sub_824FD240+0x24 to be invoked (AUDIT-068 Session 4). Two observations:

1. The arena VA itself is now allocatable in ours. The previous "unmapped VA" fault under Review A Step 1's --force-spawn-workers crowbar should no longer trip on the mapping (the VA exists). But:
2. The arena would only be naturally allocated if the upstream guest PPC code-path that calls MmAllocatePhysicalMemoryEx with X_MEM_LARGE_PAGES and lands the arena there ever fires in ours. In 2.H, the boot trajectory still wedges at the same point — meaning the ctx-installer chain (per AUDIT-068 S4 the sub_824F8398 → sub_824F7CD0 → sub_824F7800 → sub_824FD240+0x24 sequence) is downstream of the wedge and never executes.

The 2.H fix is necessary (every cooperating subsystem now has ctx_ptr in the right bucket — see the 0xbe8cbb3c, 0xbd184a40, 0xbc6c5580 entries which DO fire pre-wedge) but not sufficient to break the wedge. The wedge is still at sub_821CB030+0x1AC per AUDIT-049, upstream of the AUDIT-068 install epoch (host_ns ≈ 9.4 s on canary, ~13× later than ours's wedge at ~810 ms).

Tripstone audit

• #28 (per-engine tid stability): the ctx_ptr comparison is keyed on entry_pc (stable across engines) — never on the host-side tid label.
• #39 (composite progression metric): the PRIMARY gate is structural (bucket-range parity), explicitly NOT a swaps/draws/RT progression claim. The fix is NOT advertised as progression. Indeed, the event-count is identical to 2.F (118,149) — guest progression is unchanged.
• #40 (single-keystone framing): the framing "vA0000000 is the keystone" is PARTIALLY FALSIFIED. The structural gate passes (closing one real bug), but the predicted downstream cascade (workers spawn → producers fire → wedge unblocks) does NOT follow. Retained on its own merits; not advertised as the keystone.

Confidence

HIGH that the patch correctly maps MmAllocatePhysicalMemoryEx large-page requests to the canary vA0000000 heap range. HIGH that this is a real bug fixed (the previous 0x4xxxxxxx addresses are factually wrong vs canary's heap layout). HIGH that the cascade does not follow (3-of-3 cascade gates flat: identical event count, identical thread set, same wedge). MEDIUM that this fix is on the critical path of the AUDIT-068 ctx-installer chain — necessary but downstream of the unidentified upstream cause that prevents sub_824F8398 from firing in ours at all.

Next iterate recommendation

NOT a follow-up vA-bucket-extension iterate. The vC0000000 / vE0000000 buckets are still on the legacy heap_alloc at 0x4000_0000; this is structurally wrong but unobserved on the boot trajectory (no calls in our window request 16MB or 4KB pages — the three diverging thread.creates all routed via the 64KB X_MEM_LARGE_PAGES flag, confirmed by their landing in the new allocator).

Recommended next: iterate-2I attacks the upstream cause of the AUDIT-068 install-chain non-firing. Two candidate angles:

• (i) Mine canary phase-a log for the kernel-call sequence in the window host_ns ∈ [0, 1.0]s (well before the install epoch) and diff vs ours's 2.H phase-a log. The first kernel-call mismatch in that window is upstream of every observable wedge / spawn divergence. ~0 engine LOC, pure data work.
• (ii) Re-attempt Review A Step 1's --force-spawn-workers now that 0xBCE25640 is allocable. Workers may still fault on missing vtable entries (the [ctx+44] = 0x8200A1E8 write is a game-side ctor that hasn't run), but the fault-class will shift from "unmapped page" to "uninitialized vtable" — a more informative divergence.

Artifacts

Under xenia-rs/audit-runs/iterate-2H-physical-heap-vA/:

• ours-cold.jsonl (118,149 events, 50M-instr run, phase-a log, md5sum 1aa11b1a4839ca8b670f53f29df2c885)
• ours-cold.stdout.log / ours-cold.stderr.log (empty — quiet mode)
• writer-report.md (this file)

Patch summary (text form, for review)

diff --git a/crates/xenia-kernel/src/state.rs b/crates/xenia-kernel/src/state.rs
+    pub physical_heap_cursor: std::sync::atomic::AtomicU32,
+            physical_heap_cursor: AtomicU32::new(0xC000_0000),
+    pub fn physical_heap_alloc(&self, size: u32, mem: &GuestMemory) -> Option<u32> {
+        use std::sync::atomic::Ordering;
+        if size == 0 { return None; }
+        let aligned_size = (size + 0xFFFF) & !0xFFFF;
+        let base = loop {
+            let cur = self.physical_heap_cursor.load(Ordering::Relaxed);
+            let new_cur = cur.checked_sub(aligned_size)?;
+            if new_cur < 0xA000_0000 { return None; }
+            match self.physical_heap_cursor.compare_exchange(
+                cur, new_cur, Ordering::Relaxed, Ordering::Relaxed,
+            ) { Ok(_) => break new_cur, Err(_) => continue }
+        };
+        let protect = MemoryProtect::READ | MemoryProtect::WRITE;
+        mem.alloc(base, aligned_size, protect).ok()?;
+        Some(base)
+    }

diff --git a/crates/xenia-kernel/src/exports.rs b/crates/xenia-kernel/src/exports.rs
-    let size = ctx.gpr[4] as u32;
+    let size = ctx.gpr[4] as u32;
+    let protect_bits = ctx.gpr[5] as u32;
…
-    match state.heap_alloc(size, mem) {
+    const X_MEM_LARGE_PAGES: u32 = 0x2000_0000;
+    let result = if protect_bits & X_MEM_LARGE_PAGES != 0 {
+        state.physical_heap_alloc(size, mem)
+    } else {
+        state.heap_alloc(size, mem)
+    };
+    match result {