From 1fdbf4ea8c17dab2b8fca6b5e58c2a6d3bc7596d Mon Sep 17 00:00:00 2001 From: Arthur Hanson Rasmusson Date: Tue, 29 Sep 2026 15:29:00 -0400 Subject: docs: record physical-GPU integration mechanism and refresh project status - add docs/03-architecture/08-physical-gpu-integration.md: interfaces that exist, mechanism options A-E, chosen path (module-owned GPU driven through its real GSP firmware), sharing policy, decision record - update 06-host-module-and-hybrid-model, 02-practical-challenges, system overview, known-knowns, docs/README reading order and CUDA-side docs to match - correct stale engine-topology/COPY14 blocker claims across the tree - add STATE-CURRENT.md as the dated public status snapshot --- userspace/cuda/docs/05-570.144-decompilation.md | 15 +++++++++++---- 1 file changed, 11 insertions(+), 4 deletions(-) (limited to 'userspace/cuda/docs/05-570.144-decompilation.md') diff --git a/userspace/cuda/docs/05-570.144-decompilation.md b/userspace/cuda/docs/05-570.144-decompilation.md index 4e23866..deec463 100644 --- a/userspace/cuda/docs/05-570.144-decompilation.md +++ b/userspace/cuda/docs/05-570.144-decompilation.md @@ -89,12 +89,13 @@ This is the mechanism described in `docs/01` §2.2/§2.3: the wrapper does the tracing/tool callbacks and then calls the hand-written implementation. When chasing a call, follow the slot; when a tool interposes, the slot changes. -## 3. The `cuCtxCreate` path: crash solved, engine topology blocking +## 3. The `cuCtxCreate` path: crash and engine topology solved, completion is the frontier The 2026-09 crash was deterministic: on a fresh guest `cuCtxCreate` segfaulted -at `libcuda+0x453f90`. That is **solved** (§3.5). The call now returns -`rc=999` (`CUDA_ERROR_UNKNOWN`), and the active blocker is engine topology — -the emulated engine list is missing the async copy engine (§3.6). +at `libcuda+0x453f90`. That is **solved** (§3.5). The engine inventory is now +complete (the async copy engine is included); the call proceeds into context +creation and currently ends in a forced `rc=999` on a completion wait. The +sections below are the historical analysis of that call path. Fault facts from the crash period (live traces, corrected decompilation): @@ -233,6 +234,12 @@ the alloc reply's class-size copy-back described above. ### 3.6 Current blocker (2026-09-23): the missing async copy engine +> **Status update (2026-09-29): resolved.** The emulated inventory now includes +> the async copy engine (two GRCEs), and the class list, engine list and +> capabilities agree; the `rc=999` seen today comes from a completion wait in +> the work/translation path, not from engine topology. The analysis below is +> kept as the record of how the topology blocker was diagnosed and fixed. + With the copy-back fixed, the walker completes but `cuCtxCreate` returns `rc=999` (`CUDA_ERROR_UNKNOWN`); `cuMemAlloc` and later calls are not reached. Measured with the guest ioctl trace plus a host A/B oracle (the same libcuda -- cgit v1.2.3