site: 2026-10-20 status refresh - guest CUDA kernel execution working

1 files changed, 18 insertions, 14 deletions

diff --git a/wiki/CUDA-Userspace-Driver.md b/wiki/CUDA-Userspace-Driver.md
index 9a041ef..6975a1d 100644
--- a/wiki/CUDA-Userspace-Driver.md
+++ b/wiki/CUDA-Userspace-Driver.md
@@ -1,16 +1,20 @@
 # CUDA Userspace Driver (`libcuda.so`) — Analysis Deep Dive
 
-> **Status (2026-10-12, honest).** The analysis covers the whole library for
+> **Status (2026-10-20, 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, `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:
+> physical execution path and now execute on the physical GPU — the
+> engine-authored completions relay to the guest and its synchronisation
+> waits resolve. The vector-add (`VADD n=32768 bad=0`), matrix-multiply
+> (`MATMUL n=256 bad=0`) and transformer (`dh=256 seq=64 bad=0`,
+> `FFN4 layers=4 bad=0`) clients verify green on fresh boots. The
+> large-buffer staged-transfer class (multi-megabyte transfers between guest
+> memory and device memory) is under repair, and reproducibility across fresh
+> boots is being re-measured after the boot-poisoning fix. 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);
@@ -172,19 +176,19 @@ the data plane (`docs/08`).
   emulation and object/control replies are implemented; the stock guest stack
   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
+* **Current frontier:** guest CUDA kernel launches execute on the physical
+  GPU with engine-authored completions relayed to the guest; the verified
+  clients are green on fresh boots. The leading edge is the large-buffer
+  staged-transfer class (some large multi-chunk clients still mis-verify),
+  re-measurement of reproducibility across fresh boots after the
+  boot-poisoning fix, and per-guest execution isolation. 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 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.
+  the physical backend; kernel launches now execute on the engine through
+  the forwarded path, with completions relayed back to the guest.
 
 ## 5. The crash-path lesson: replies are consumed data