STATE-CURRENT: runtime client reaches kernel launch; execution backend is the next wall

- runtime init rc=0 (cudaGetDeviceCount/SetDevice/alloc/HtoD/launch accepted)
- fixed the legacy clock-domain probe replies that blocked runtime init
- next: real-release runtime init and physical-GPU execution of queued work

1 files changed, 25 insertions, 16 deletions

diff --git a/STATE-CURRENT.md b/STATE-CURRENT.md
index 6712b77..4846c24 100644
--- a/STATE-CURRENT.md
+++ b/STATE-CURRENT.md
@@ -1,6 +1,6 @@
 # Open-IOV Current State
 
-> **Snapshot: 2026-09-30 14:02.** This is a dated public status page, not live
+> **Snapshot: 2026-09-30 15:48.** This is a dated public status page, not live
 > state; it is refreshed on every progress check. Live working notes are
 > maintained outside this repository; the public known-knowns/unknowns document
 > is authoritative here:
@@ -30,7 +30,7 @@ meant to execute on the physical GPU.
 | CUDA userspace: `cuInit`, `cuDeviceGetCount`, `cuDeviceGet` | ✅ |
 | `cuCtxCreate` returns | ✅ (the whole smoke test now completes) |
 | `cuMemAlloc` + `cuMemcpy` roundtrip (`ALL OK` in the smoke test) | ✅ payload roundtrip verified 64/64 in the guest |
-| Full `nvidia-smi` output | ❌ next: run real CUDA workloads in the guest |
+| Full `nvidia-smi` output / kernel launch | 🟡 the static runtime now initializes (`rc=0`) and queues a kernel launch; execution awaits the backend |
 | CUDA kernel execution (`vectorAdd`) | ❌ not started (forwarding layer absent) |
 | Graphics (3D), video | ❌ |
 | Faults, multi-version, Windows, migration, multi-tenancy, performance | ❌ |
@@ -68,19 +68,22 @@ chain succeeds.
   the copy-engine decoder consults pinned translations before the scanned
   map, so every push-data operation executes (`memset=19473`, `ringops=10551`
   live).
-- **Runtime client status**: the static-runtime `vectorAdd` client is now past
-  the registration/tracker wall - the host's releases land, UVM observes the
-  completed wait and registration returns success. It still returns an
-  initialization error a few hundred milliseconds later, with no kernel-side
-  error; that post-registration failure is in libcuda and is being traced.
-- **One real emulation bug fixed**: the BAR-info control replied with the
-  wrong parameter size, so the guest's reply cache rejected it; the canonical
-  struct is now returned. One cache-set mismatch remains once per boot and is
-  being identified.
-- Active work: identify the remaining reply-cache mismatch, capture the
-  runtime client's post-registration stack if needed, and close the
-  device-address walk gap for the runtime's own buffers before attempting
-  allocation/kernel launches.
+- **The runtime client now initializes and reaches kernel launch**: with a
+  static-runtime `vectorAdd` client, `cudaGetDeviceCount`, `cudaSetDevice`,
+  `cudaFree`, three `cudaMalloc`, the HtoD copies and `cudaGetLastError` all
+  return success. The client then parks in `cudaDeviceSynchronize` - the
+  launch is queued but never **executed**, because real execution requires
+  the physical-GPU backend (the next project).
+- **What fixed it**: the failing call was never a kernel call - it was the
+  clock-domain probe inside libcuda (two device attributes) whose three
+  legacy clock controls were answered with zeros; they are now populated
+  with exactly the fields the helper checks.
+- **Caveat**: the rc=0 init chain above was obtained in fast-release mode;
+  under real releases the runtime-init path still needs the pin/translation
+  work (the smoke-test baseline is already correct under real releases).
+- Active work: (1) real-release delivery for the runtime init (pin/translation
+  work); (2) decode the queued compute-channel pushes into real submissions on
+  the physical GPU (the execution backend); then the synchronize/DtoH verify.
 - Observability: a size-keyed copy watch, a VRAM shadow dump/search, and an
   operation log are now module parameters, and the test's output survives
   guest-agent stalls via the serial console.
@@ -137,7 +140,9 @@ Status tags: `[done]`, `[frontier]` (actively worked), `[partial]`,
         v
  [done] ------------------------------------------------>  cuMemAlloc + cuMemcpy roundtrip
         |                                                  (passes end-to-end; payload 64/64 correct)
- [not yet] --------------------------------------------->  full nvidia-smi output / kernel launch
+ [partial] --------------------------------------------->  full nvidia-smi output / kernel launch
+        |                                                  (runtime init rc=0; launch queued;
+        |                                                   execution awaits the backend)
 ```
 
 Work execution (host service vs client synchronization):
@@ -146,6 +151,8 @@ Work execution (host service vs client synchronization):
  [done] host decodes guest pushes (method streams): memsets, copies, releases
            - CE pushes execute at scale; the compute-class inline-DMA HtoD and
              the copy-engine-on-compute DtoH both execute; payload 64/64
+           - the runtime client now initializes (rc=0) and queues a kernel
+             launch; the queued compute pushes decode but are not executed
  [partial] GPU VA -> guest PA translation: page-table walk fixed and succeeding;
            server-owned page-table population still in progress
  [not yet] real work forwarded to the physical GPU (host-RM proxy or direct submission)
@@ -173,6 +180,8 @@ Recent chain of walls removed (2026-09-28 to 2026-09-30):
    -> cuCtxCreate OK; payload found (compute-class inline DMA)
    -> GMMU walk decode fixed (child/leaf encoding) -> inline HtoD lands
    -> DtoH copy-engine-on-compute allowed -> payload roundtrip 64/64
+   -> runtime client initializes rc=0 (legacy clock-domain fix) -> kernel launch
+      queued -> execution backend is the next wall
 ```
 
 ## Tools, code paths and fixes behind this progress