diff options
Diffstat (limited to 'wiki/CUDA-Userspace-Driver.md')
| -rw-r--r-- | wiki/CUDA-Userspace-Driver.md | 42 |
1 files changed, 25 insertions, 17 deletions
diff --git a/wiki/CUDA-Userspace-Driver.md b/wiki/CUDA-Userspace-Driver.md index 3fa5d41..9a041ef 100644 --- a/wiki/CUDA-Userspace-Driver.md +++ b/wiki/CUDA-Userspace-Driver.md @@ -1,13 +1,17 @@ # CUDA Userspace Driver (`libcuda.so`) — Analysis Deep Dive -> **Status (2026-09-23, honest).** The analysis covers the whole library for +> **Status (2026-10-12, honest).** The analysis covers the whole library for > driver 570.144 and the tooling is version-agnostic. The *control plane* gets -> the stock guest stack through `cuInit`, device enumeration and into -> `cuCtxCreate`, which is blocked at `rc=999` because the emulated engine list -> is missing the async copy engine `COPY14`. The *data plane* is at the -> software memop bridge: the host executes the memsets, copies and semaphore -> releases it decodes from guest push buffers, and **no CUDA kernel has been -> forwarded yet**. Canonical detail: [`01-architecture.md`](../userspace/cuda/docs/01-architecture.md) +> the stock guest stack through `cuInit`, device enumeration, `cuCtxCreate` +> and the full driver-API smoke test — allocation, copies, free and destroy +> complete end to end (`ALL OK`; the 64-byte payload round-trips exactly). +> The *data plane* decodes guest push buffers and executes the memory and +> semaphore work it understands; CUDA kernel launches are forwarded to the +> physical execution path, where a launch reaches the engine queue +> (front-end deposit and scheduling are observed) but an engine-authored +> release is not yet observed. Green runs are not yet reproducible on every +> boot — an open issue, tracked in the repository. Canonical detail: +> [`01-architecture.md`](../userspace/cuda/docs/01-architecture.md) > through `08`; reading order > [`../userspace/cuda/READ-ME-FIRST.md`](../userspace/cuda/READ-ME-FIRST.md); > front door [`../docs/README.md`](../docs/README.md). @@ -166,17 +170,21 @@ the data plane (`docs/08`). it — work path abstracted from day one. * **Control plane today:** GSP-RM emulation, RPC handling, BAR/PCI/MSI-X emulation and object/control replies are implemented; the stock guest stack - gets through `cuInit` and device enumeration into `cuCtxCreate`. -* **Current blocker:** `cuCtxCreate` returns `rc=999` (`CUDA_ERROR_UNKNOWN`) - because the class-filtered engine list is missing the async copy engine - `COPY14` (descriptor `0x793ceb0e`, instance 14, client type `0x38`, class - `0xc9b5`). The oracle list has 7 engines (GR, CE0..CE4, `COPY14`); the guest - list has 6. The driver silently skips engines with no per-(class, instance) - database entry, then reads a zeroed secondary record and rolls back; what - builds that database entry is the open question (`docs/05` §3.6–3.7). + completes `cuInit`, device enumeration, `cuCtxCreate` and the driver-API + smoke test (allocation, copies, free and destroy). +* **Current frontier:** a guest CUDA kernel launch is forwarded and reaches + the physical engine queue — the front end deposits the launch and the + scheduling path accepts it — but the engine does not yet execute the + forwarded launch descriptor: an engine-authored release is the only proof + of execution and it is not observed. The per-boot green/stall variance on + the emulation path is an open issue, tracked in the repository. The chain, + the evidence and the live state are on + [`Execution-Frontier.md`](Execution-Frontier.md). * **Data plane today:** the host module decodes guest push buffers as method - streams and **executes the small work it understands itself** — memsets, - copies and semaphore releases. **No CUDA kernel has been forwarded yet.** + streams and executes the memory and semaphore work it understands + (memsets, copies, semaphore releases), and forwards engine-class work to + the physical backend; kernel launches are forwarded but not yet executed + by the engine. ## 5. The crash-path lesson: replies are consumed data |