STATE-CURRENT: check-back snapshot (2026-10-06 10:57) - GR context partial acceptance, golden lane walled, engine dispatch still absent

1 files changed, 28 insertions, 4 deletions

diff --git a/STATE-CURRENT.md b/STATE-CURRENT.md
index c4566dd..ce10d48 100644
--- a/STATE-CURRENT.md
+++ b/STATE-CURRENT.md
@@ -1,7 +1,7 @@
 # Open-IOV Current State
 
 > **Snapshot: 2026-10-05 (reorganized; simulator status current 2026-10-04,
-> physical/guest campaign data as of 2026-10-05 ~15:55; debugging-options
+> physical/guest campaign data as of 2026-10-06 ~10:55; debugging-options
 > catalogue added 2026-10-05).** 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
@@ -72,9 +72,33 @@ isolation, performance, portability).
    green, the PB sysmem step is client-local (`rpc_result=0x22`), and a bare
    `TURING_A` (0xc597) class alloc on the ladder channel does not initialize
    the instance (NOCAT byte-identical to grs22). Next named step: the full
-   FWCLIENT client-managed construct (client MAIN/PATCH/PM/global allocs +
-   channel-VAS mapping + the reference promote set). Two clean cycles, GPU
-   green.
+    FWCLIENT client-managed construct (client MAIN/PATCH/PM/global allocs +
+    channel-VAS mapping + the reference promote set). Two clean cycles, GPU
+    green. **Update 2026-10-06 ~10:55:** the golden-replay ladder and the
+    client-managed FWCLIENT construct were exercised through their full
+    elimination matrix (all supervised, clean teardowns; in-session PCI
+    function-level reset where an RM task hung - no reboots). Results:
+    (a) individual-entry bisection shows the resource manager accepts PM,
+    PATCH, PRIV_ACCESS_MAP and UNRESTRICTED_PRIV_ACCESS_MAP context buffers
+    one at a time and refuses FECS_EVENT (`0x1f`), so the context can be
+    partially completed but not completed; (b) the "golden execution lane" is
+    walled - an RM-managed golden channel tolerates only its exact captured
+    server-owned shape, and attaching client submission wiring (GPFIFO ring
+    or system-memory USERD) makes the next GR object construct hang;
+    (c) the full captured 208-dword guest launch push is decoded and
+    byte-validated and the forward maps every page, yet across the whole
+    hypothesis matrix (verbatim replay, QMD prewrite + explicit PCAS,
+    INITIALIZE_CTX, per-channel compute init, no-SET_OBJECT, sized FBMEM aux,
+    server-managed context) the physical GR engine still never processes the
+    forwarded launch: the inline-QMD destination stays zero, no release
+    fires, no engine fault is recorded. Correction to earlier notes: GPFIFO
+    GET progress and the channel report semaphore are authored by the
+    front-end (PBDMA), not by the GR engine, so they do not prove engine
+    execution. A full individual acceptance-sweep cycle was live at snapshot
+    time. The intermittent guest `cudaMalloc` stall class now has concrete
+    (unvalidated) fix candidates: pool-VA resolution ordering before fallback,
+    and verification of an unreadable entry before it is consumed. Host
+    clean; pstore empty.
 - **Guest frontier: FIRST GREEN END-TO-END GUEST CUDA, NOW UNDER HARDENING
   (2026-10-04 ~16:20; hardening 2026-10-05 overnight).** The emulation-only
   ("no-claim") campaign runs an unmodified guest CUDA program to completion