ef93a4fa14
Source changes (dormant parity infra, retained from iterate 2.AI/2.AO): - xenia-kernel/exports.rs: nt_create_event manual_reset polarity + related event wiring - xenia-gpu/mmio_region.rs: D1MODE_VBLANK_VLINE_STATUS hardcode parity Also lands the audit-runs/ analysis notes (.md/.txt/.json digests) for the iterate 2.x VSync/0x10e8/0x1004 wedge investigation. Raw trace dumps (.jsonl/.gz/.csv/.stdout) and agent worktrees (.claude/) are gitignored as regenerable local artifacts — see memory + HANDOFF for the running findings. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
111 lines
4.6 KiB
Markdown
111 lines
4.6 KiB
Markdown
# Phase 0–2 — XAM hallucination audit (Phase C+6½ XAM)
|
||
|
||
## Method
|
||
|
||
For every xam.xex ord ours registers in `crates/xenia-kernel/src/xam.rs::register_exports()`,
|
||
cross-reference against canary's `xam_table.inc` (1736 entries; authoritative
|
||
Xbox 360 ord→name mapping). Three classes of mismatch are possible:
|
||
|
||
1. **MATCH** — ours's name == canary's name. Most exports.
|
||
2. **HALLUCINATION** — ours's name ≠ canary's name at the same ord.
|
||
The hallucinated name may be a real NT/Xam function that exists at a
|
||
*different* ord on Xbox 360, making it look plausible.
|
||
3. **GHOST ORD** — ours registers an ord canary's table doesn't have.
|
||
|
||
For each HALLUCINATION, additional severity classification (per C+6½ taxonomy):
|
||
|
||
* **CRITICAL** — ours's stub body performs different semantics than
|
||
canary's named function. Game gets wrong data on every call.
|
||
* **HIGH** — ours's stub body is harmless (e.g. `stub_success`) but
|
||
registered under wrong name (Phase A name divergence; no behavior
|
||
risk at runtime).
|
||
* **LOW** — ours's stub body has correct semantics but name is wrong
|
||
(rename-only fix).
|
||
|
||
## Headline
|
||
|
||
| count | category |
|
||
|------:|---|
|
||
| 52 | total xam ords ours registers |
|
||
| **52** | **MATCH** (name agrees with canary table) |
|
||
| **0** | **HALLUCINATION** |
|
||
| **0** | **GHOST ORD** (no ord registered in ours that canary's table lacks) |
|
||
|
||
**Outcome: clean. The XAM table has zero name mismatches.**
|
||
|
||
This is in contrast to the xboxkrnl table audited in C+6½, which had 2
|
||
CRITICAL hallucinations (ord 0x82 `KeQueryIdealProcessor` →
|
||
`KeQueryInterruptTime`; ord 0x98 `KeSetIdealProcessor` →
|
||
`KeSetBackgroundProcessors`). Whoever populated ours's XAM
|
||
registrations evidently used canary's `xam_table.inc` as the
|
||
authoritative source from the start.
|
||
|
||
## XamTaskCloseHandle (Phase C+7 target) — explicit verification
|
||
|
||
Phase C+7's pending main-chain first divergence at idx 102158 is
|
||
`XamTaskCloseHandle return_value=1 vs 0`. Audit confirms:
|
||
|
||
* Ord **0x000001B1** in ours's `xam.rs:33` ↔ canary's
|
||
`xam_table.inc:230` are BOTH `XamTaskCloseHandle`.
|
||
* **NOT a name hallucination.** Both engines call the same function
|
||
by name.
|
||
* The divergence is a **body-semantic issue**:
|
||
* canary's `XamTaskCloseHandle_entry` (`xam_task.cc:83-93`) calls
|
||
`NtClose(obj_handle)`, returns `true` (= 1) on success.
|
||
* ours registers `stub_success` (`xam.rs:33`) which returns 0.
|
||
* The fix is therefore in xam_task body semantics, NOT in this
|
||
hallucination-audit scope. **Deferred to a dedicated C+7 session**
|
||
per directive "don't widen scope to fix non-hallucinated XAM
|
||
functions".
|
||
|
||
## Class-E sister-sweep candidate (Phase 1 — applied)
|
||
|
||
While auditing 52 ours-registered XAM ords, cross-referenced which
|
||
have NO `DECLARE_XAM_EXPORT` shim in canary (analogous to C+6½'s
|
||
class-E sister sweep on xboxkrnl).
|
||
|
||
Canary's XAM `DECLARE_XAM_EXPORT*` count: **331 shims** declared
|
||
across all `src/xenia/kernel/xam/*.cc` files.
|
||
|
||
Of ours's 52 ords, exactly **one** has a matching name but NO shim
|
||
in canary, and is currently registered via the noisy
|
||
`register_export` path:
|
||
|
||
| ord | canary name | ours kind (pre) | canary has shim? |
|
||
|---|---|---|---|
|
||
| 0x02D5 | XamShowGamerCardUIForXUID | register_export → stub_success | NO (table-only) |
|
||
|
||
Wait, isn't `XamShowDirtyDiscErrorUI` also class-E? It IS class-E in
|
||
canary (table-only), but the audit reviewed and it's already
|
||
correctly named and the directive constrains us to bug-class-aware
|
||
scope: the 1 candidate flagged is the only one ours is currently
|
||
registering through the loud (event-emitting) path under a class-E
|
||
name that we have evidence (from C+6 / C+6½) would alter Phase A
|
||
matched-prefix if hit.
|
||
|
||
(Note: ALL other ours `register_export(..., stub_*)` entries with no
|
||
canary `DECLARE_XAM_EXPORT` shim were spot-checked. None are
|
||
currently live in the 50M Phase A window — confirmed by grep of the
|
||
C+6½ ours.jsonl. So even if any others are technically class-E,
|
||
they're inert at the current matched-prefix horizon. Per directive
|
||
"don't widen scope", only the 1 flagged candidate is touched.)
|
||
|
||
**Phase 1 action**: rewire ord 0x02D5 to
|
||
`register_unimplemented_export`. Mirrors C+6½'s
|
||
`StfsCreateDevice`/`DbgPrint`/etc rewires.
|
||
|
||
## No CRITICAL/HIGH/LOW hallucinations to fix
|
||
|
||
Per the audit headline. The session's primary deliverable
|
||
(hallucination fixes) is **empty by construction** — the XAM table
|
||
in ours was already clean.
|
||
|
||
## Files
|
||
|
||
* `canary-xam-table.csv` — 1736 raw entries from
|
||
`xam_table.inc`.
|
||
* `canary-xam-table-classified.csv` — same, with
|
||
`has_shim` column (yes/no per `DECLARE_XAM_EXPORT*` grep).
|
||
* `canary-xam-declared-shims.txt` — 331 names.
|
||
* `ours-vs-canary.csv` — 52-row cross-check with verdict per ord.
|