82f3d611e2
The pre-fix VdSwap zero-filled the guest's reserved buffer with NOPs and
called `state.gpu.notify_xe_swap` directly — bypassing the ring, leaving
the PM4_XE_SWAP handler at gpu_system.rs:1232 dead code, and skipping
the PM4_TYPE0(SHADER_CONSTANT_FETCH_00_0, 6) patch. Sylpheed's bloom/
blur "sample frame N for frame N+1" path samples fetch-constant slot 0
expecting the frontbuffer descriptor; without the patch, slot 0 stayed
stale and any shader sampling it read garbage.
This commit writes the canary VdSwap PM4 sequence directly into the
primary ring at the current write pointer (read via the shared MMIO
atomic), then advances WPTR over the injection. The natural CP drain
consumes PM4_XE_SWAP — bumping `swaps_seen` and patching fetch-constant
slot 0 — without going through any direct kernel→GPU bypass.
Sequence per xenia-canary VdSwap_entry (xboxkrnl_video.cc:438-521):
1) PM4_TYPE0(0x4800, count=6) + 6 fetch-header dwords (with
base_address re-patched from virtual to physical >> 12).
2) PM4_TYPE3(PM4_XE_SWAP, count=4) + signature + frontbuffer_phys
+ width + height.
Mechanism notes:
- buffer_ptr in xenia-rs is in the system command buffer, NOT the
primary ring (verified empirically: buffer_ptr=0x4acd4df8 vs
ring_base=0x0accb000, size 4 KB). Canary's VdSwap writes to
buffer_ptr because its ring layout maps the reserved slot inside
the ring; xenia-rs's doesn't, so we have to write at the actual
ring WPTR address (cached on KernelState.ring_base from
VdInitializeRingBuffer).
- The original "buffer_ptr zero-fill + bump WPTR by 64" path is
preserved before the injection — it exposes any game-batched PM4
packets and keeps the buffer_ptr region skippable per existing
game compat behavior.
- A safety-net fallback at the end calls `notify_xe_swap` directly if
swaps_seen didn't advance during the drain (e.g. a ring-arithmetic
edge case). Idempotent — only fires when the PM4 path didn't.
- KRNBUG-Mm-04 deferred: virt→phys uses the masked stub
`virt & 0x1FFF_FFFF`, sufficient for the standard heap.
Mechanical changes:
- crates/xenia-gpu/src/pm4.rs: add make_packet_type0 / type2 / type3
helpers + round-trip unit test (mirrors canary xenos.h:1682-1709).
- crates/xenia-gpu/src/handle.rs: add mmio_cp_rb_wptr_load accessor
(Acquire-load) so the kernel can compute ring offsets.
- crates/xenia-kernel/src/state.rs: cache ring_base / ring_size_dwords
on KernelState (set by VdInitializeRingBuffer).
- crates/xenia-kernel/src/exports.rs: rewrite the vd_swap PM4-emit
block; patch fetch_dwords[1] base_address virt→phys before injection.
Verification at -n 100M lockstep:
swaps: 2 → 2 (game fires VdSwap exactly twice)
draws: 0 → 0 (gated by Phases D+E)
fallback warning: 0 occurrences (PM4 path consumed both swaps)
instructions: ~100M
Tests: 552 passing (553 with new pm4 round-trip test). Lockstep
stable-fields determinism: byte-identical across two 100M runs.
The "swaps > 2" prediction in the audit's plan assumed the game would
fire VdSwap more often once the path worked; empirically Sylpheed only
calls VdSwap twice within 100M instructions (this is the renderer
plateau the audit identified). The success criterion for Phase C is
that the PM4 path is now operational, which Phases D+E require for
visible draws.
Closes KRNBUG-Vd-04, GPUBUG-001, XMODBUG-013.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
xenia-rs
Rust reimplementation of the Xbox 360 emulator xenia, focused on reverse-engineering and preservation rather than full-speed play. The initial target is Project Sylpheed — Arc of Deception; getting the title disassembled, traced, and far enough into its init path to understand its engine.
Heavy cross-reference to xenia-canary for CPU context setup, kernel export behavior, and XEX loading semantics.
Status
- XEX loader — XEX2 header parsing, LZX decompression, AES decryption, PE section parsing.
- VFS / XISO — XGD2 dual-layer disc images (with the 0x0FD90000 partition offset).
- PPC interpreter — 200+ opcodes, PowerPC 32/64-bit GPR/FPR, VMX128 decoding.
- Static analyzer — function discovery (prolog/epilog heuristics), cross-references, labels, save/restore helper detection, assembly text + SQLite database output.
- Kernel HLE — minimal subset driving Project Sylpheed: ~170 xboxkrnl + xam exports (critical sections, events, TLS, virtual memory, Vd stubs, XAM input/user/content).
- Debugger — in-memory step/break, SQLite execution + import-call + branch tracing.
Not yet: GPU (xenos/xe-shader), APU audio, HID, kernel scheduler, full threading, exception delivery.
Workspace
crates/
xenia-types # shared primitive types, bitflags
xenia-memory # guest memory, paged allocator, page table
xenia-cpu # PPC decoder, interpreter, context
xenia-xex # XEX2 loader, PE parser, LZX, AES
xenia-vfs # XISO / disc-image reader
xenia-kernel # HLE kernel state, exports, XAM
xenia-gpu # (stub) Xenos command processor
xenia-apu # (stub) XAudio
xenia-hid # (stub) XInput
xenia-debugger # in-memory trace, breakpoints, step modes
xenia-analysis # function/xref analysis, assembly formatter, SQLite DbWriter
xenia-app # `xenia-rs` CLI binary
CLI
Build:
cargo build --release
The binary xenia-rs accepts XEX2 files or ISO / XISO disc images as input
(the loader auto-detects discs and extracts default.xex).
info / browse / disasm
Quick header / disc / first-N-instructions inspection. See --help.
extract — unpack PE + metadata
xenia-rs extract <xex-or-iso> [-o <out-dir>] [--db <sqlite-path>]
Writes <name>.pe (decompressed/decrypted PE image) and <name>.xex.json
(header metadata). With --db, also emits a SQLite database containing the
base tables: metadata, sections, imports.
dis — full disassembly
xenia-rs dis <xex-or-iso> [-o <asm-file>] [--db <sqlite-path>] [--quiet]
Runs function + cross-reference analysis and produces:
- assembly text to stdout or
-o <file>(unless--quiet) - optional SQLite DB with the base tables + disasm tables:
functions,labels,instructions,xrefs
exec — interpret with tracing
xenia-rs exec <xex-or-iso> [-n <max-instrs>] [--db <sqlite-path>]
[--trace-instructions] [--trace-imports] [--trace-branches]
Loads the title, initializes CPU state per xenia-canary, intercepts import
thunks with HLE kernel calls, and interprets from the entry point. Without
-n, runs until halt/fault. With --db, produces a DB that is a superset
of dis --db plus opt-in trace tables:
| flag | table | rows |
|---|---|---|
--trace-instructions |
exec_trace |
one row per interpreted instruction (PC, r3/r4, LR, SP) |
--trace-imports |
import_calls |
one row per kernel/XAM call (module, ordinal, args) |
--trace-branches |
branch_trace |
taken branches classified as call/return/jump/branch |
Cumulative DB layering
Each command's DB is a superset of the previous. A single
xenia-rs exec <iso> --db full.db --trace-instructions --trace-imports --trace-branches
produces the full picture in one pass — base tables, complete static
disassembly, and runtime traces correlatable by address/cycle.
Performance knobs
XENIA_DB_BATCH_SIZE— rows per streaming commit / trace-buffer flush (default100_000). Lower values reduce memory use; higher values reduce fsync overhead on slow disks.
The DB writer uses journal_mode=OFF, synchronous=OFF, locking_mode=EXCLUSIVE
and commits in batches; no ANALYZE is run at finalize. Indices are created
after bulk insertion with progress messages.
Example queries
-- Top 20 kernel functions called during early init
SELECT name, COUNT(*) FROM import_calls GROUP BY name ORDER BY 2 DESC LIMIT 20;
-- All basic-block leaders (targets of taken branches) not already labelled
SELECT DISTINCT bt.target
FROM branch_trace bt LEFT JOIN labels l ON l.address = bt.target
WHERE l.address IS NULL;
-- Correlate a traced call site with its static disassembly
SELECT et.cycle, i.disasm, i.ext_disasm
FROM exec_trace et JOIN instructions i ON i.address = et.address
WHERE et.address = 0x824AB748 ORDER BY et.cycle;
License
BSD-3-Clause, matching upstream xenia.