1 files changed, 32 insertions, 0 deletions
diff --git a/userspace/cuda/570.144/docs/ANALYSIS-cuctxcreate-segv.md b/userspace/cuda/570.144/docs/ANALYSIS-cuctxcreate-segv.md
index 9a15b51..8775b6c 100644
--- a/userspace/cuda/570.144/docs/ANALYSIS-cuctxcreate-segv.md
+++ b/userspace/cuda/570.144/docs/ANALYSIS-cuctxcreate-segv.md
@@ -159,6 +159,38 @@ The engine-list construction path for this library is summarised here:
 * Only copy-engine records with a positive runlist become async channels;
   the runlist value is reused when a channel is created (0 for GR).
 
+## Golden reference: the same code path on the host (real TU104)
+
+The host's libcuda (570.211.01) contains the **identical instruction
+sequence** for the engine-registration helper (byte pattern match; host
+vaddr `0x454470`, guest `0x453ef0`). Running the same `cdt` on the host under
+gdb (`scripts/host_gdb_descriptor.sh`) shows the helper being called with:
+
+```
+HELPER desc=0x555555571de4 obj=0x7ffff07d4c30
+  0x555555571de4: 0x00000003 0x0000000d 0x00000004 0x0000c5b5
+  0x555555571df4: 0x000003e6 0x00000003
+HOOKCALL rax=0x7ffff7898d80 hook=0x7ffff3a67cd0
+... then cuCtxCreate succeeds, ALL OK
+```
+
+So the per-engine record is **six dwords**:
+
+| off | host (working, copy engine) | guest (crashing) |
+|---|---|---|
+| +0x00 | 3 (engine class enum) | 1 |
+| +0x04 | 0xd (RM_ENGINE_TYPE COPY4) | 1 (GR0) |
+| +0x08 | 4 (runlist) | 0 |
+| +0x0c | 0xc5b5 (TURING_DMA_COPY_A) | 0xc5c0 (TURING_COMPUTE_A) |
+| +0x10 | 0x3e6 | 0 |
+| +0x14 | 3 | 0 |
+
+Both sides take the same code path and the host does not crash, so the
+difference is in the **engine records the driver hands to libcuda** (built
+from the GSP static info engine table we emulate) - in the guest the
+registration walks the GR engine with `0xc5c0`, on the host a copy engine
+with `0xc5b5` and non-zero `+0x10`/`+0x14`.
+
 ## What is NOT (yet) analysed
 
 * No full auto-analysis output was reviewed beyond the functions above;