diff options
Diffstat (limited to 'docs/03-architecture/07-driver-lifecycle-field-guide.md')
| -rw-r--r-- | docs/03-architecture/07-driver-lifecycle-field-guide.md | 33 |
1 files changed, 27 insertions, 6 deletions
diff --git a/docs/03-architecture/07-driver-lifecycle-field-guide.md b/docs/03-architecture/07-driver-lifecycle-field-guide.md index 8d80694..9de5edb 100644 --- a/docs/03-architecture/07-driver-lifecycle-field-guide.md +++ b/docs/03-architecture/07-driver-lifecycle-field-guide.md @@ -88,7 +88,9 @@ gsp-resman-vfio: queue args sharedPA=... ptes=... cmdOff=... statOff=... ## 5. Resource-manager initialization (the control battery) **Guest:** sends `GSP_RM_CONTROL` (76) for every subsystem it initializes. -Representative controls (all observed, all answered with correct shapes): +Of the ~160 observed control IDs, 23 are special-cased and answered with real +values; the rest are answered with a generic `SUCCESS` and zeroed params (the +fallback). Representative controls: | Control | Meaning | What matters | |---|---|---| @@ -103,8 +105,11 @@ Representative controls (all observed, all answered with correct shapes): | `0x20802a02` | CE PCE mask | one bit per engine | | `0x20802a08` | CE fault method buffer size | method buffer sizing | | `0x90f10106` | vaspace reserved-PDE contract | **carries page-table physical addresses** (see GSP-RM doc) | -| `0x20803039` | NVLink masks/VBIOS info | unpopulated but must be shaped | -| `0x20800a70` | BUS flush with sysmembar | UVM issues these frequently; success suffices | +| `0x20800123` / `0x20800170` | `GPU_GET_ENGINES` / `GET_ENGINES_V2` | engine inventory (filtered by the class list / classDB); values are consumed — the guest must see the full engine list, including the async copy engine (`COPY14`), and the current `rc=999` blocker lives here | +| `0x800201` | `GPU_GET_CLASSLIST` | class list (classDB); must agree with the engine list and the CE caps controls | +| `0x2080012b` | GPU_PROMOTE_CTX (560-byte params) | issued immediately before context creation; fallback generic `SUCCESS`, consumed fields not yet coherent | +| `0x20803039` | NVLink masks/VBIOS info | fallback: generic `SUCCESS` with zeroed params | +| `0x20800a70` | BUS flush with sysmembar | fallback: generic `SUCCESS` with zeroed params; UVM issues these frequently | **Log signature:** ``` @@ -125,8 +130,15 @@ CUDA process: 0xc46f TURING_CHANNEL_GPFIFO_A(368 bytes) ← the channel (GPFIFO VA, instance/userd descriptors) 0xc076 GP100_UVM_SW (0 bytes) 0xc5b5 TURING_DMA_COPY_A (8 bytes) ← CE object +0xc5c0 TURING_COMPUTE_A (16 bytes) ← compute object (engine registration path) ``` +The `TURING_COMPUTE_A` (0xc5c0) alloc is where the earlier `libcuda` segfault +was fixed: the caller issues it with `paramsSize=0` against an 8-byte stack +local while the kernel side treats the class params as 16 bytes and copies the +reply params back, so the emulation must echo the request params back in the +alloc reply instead of writing a reply the caller did not ask for. + Channel parameters decode into: `gpFifoOffset` (a GPU VA), `gpFifoEntries`, `engineType` (e.g. COPY0 = 0x9), and `NV_MEMORY_DESC_PARAMS` for instance/userd/ramfc/method buffers with @@ -149,9 +161,18 @@ page-tree init. **Device must:** let UVM's channels initialize (each channel does a first push and waits on a semaphore), and let page-tree initialization proceed. -**Emulation (today):** we can decode the pushes UVM generates and complete -their semaphore releases by translating the semaphore VA to a guest physical -address (see the UVM and host-module docs). This is the live development front. +**Emulation (today):** we can decode the pushes UVM generates and execute +their memsets, copies and semaphore releases in software by translating the +semaphore VA to a guest physical address (see the UVM and host-module docs). +This is a bridge, not forwarding: no work reaches the physical GPU yet. + +**Live development front (2026-09-23):** CUDA context creation — `cuCtxCreate` +returns `rc=999` (`CUDA_ERROR_UNKNOWN`) because the emulated engine list lacks +the async copy engine (`COPY14`). The engine-record layout and the alloc +reply-fidelity checks are the first things to inspect +([`../../userspace/cuda/docs/05-570.144-decompilation.md` §3.3/§3.6](../../userspace/cuda/docs/05-570.144-decompilation.md); +start at +[`../../userspace/cuda/READ-ME-FIRST.md`](../../userspace/cuda/READ-ME-FIRST.md)). **Log signatures (guest side):** ``` |