STATE-CURRENT: 2026-10-14 status refresh (physical guest compute, ring fix, scrubber fix)

1 files changed, 53 insertions, 4 deletions

diff --git a/STATE-CURRENT.md b/STATE-CURRENT.md
index c16b774..fc210fb 100644
--- a/STATE-CURRENT.md
+++ b/STATE-CURRENT.md
@@ -1,8 +1,9 @@
 # Open-IOV Current State
 
-> **Snapshot: 2026-10-05 (reorganized; simulator status current 2026-10-04,
-> physical/guest campaign data as of 2026-10-07 ~01:15; debugging-options
-> catalogue added 2026-10-05).** This is a dated public
+> **Snapshot: 2026-10-14 ~13:30 (physical/guest campaign data current to the
+> live r139 cycle at snapshot time; simulator workstream status 2026-10-03;
+> page reorganized and 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
 > known-knowns/unknowns document is authoritative here:
@@ -146,6 +147,48 @@ isolation, performance, portability).
      aperture. Ranked next: read the server-FBMEM fault buffer via a
      copy-engine transfer, per-VEID/compute-context execution requirements,
      and the scheduler CWD field semantics. Host clean, GPU green, no reboots.
+     **Update 2026-10-14 ~13:30 (major - guest compute runs on the physical
+     engine):** the physical-backed guest campaign now runs a multi-client
+     CUDA battery against the real TU104 with the host CUDA bridge disabled
+     (`cuda_bridge=0`, GR forwarding on). In one cycle (r137) the first client
+     (`victory_mail`: `MAIL` + `VADD bad=0` + `STATUS OK`) and the second
+     client (`smiley`: `STATUS OK`) are both green on the physical backend,
+     and the guest's compute launches execute on the physical GR engine (the
+     window-attribution defects where kernels wrote into the wrong window are
+     fixed; first-client guest VADD results verify). The 2026-10-08..12
+     second-client campaign closed its chain (CE USERD location, CE
+     push-buffer pin delivery, a channel-anchored CE pool resolver
+     `ade77d9a`, session-flush pin semantics, data-argument resolution
+     order). Wall closure since 2026-10-07: (a) the third-client
+     (`victory_matmul`) PMA-scrub freeze is root-caused live - the
+     boot-session scrubber channel's finish word is a guest-RAM vmap that
+     collides with a client VA - and fixed by authoring the scrubber
+     channel's progress (`624438bb` + guest scanner `80af379d`), so
+     `victory_matmul` gets past `cudaMalloc`; (b) the intermittent
+     GR-forward launch timeout is root-caused: the host publishes forwarded
+     launches modulo an 8-entry ladder ring while the user-lane channel was
+     declared with 1024 GPFIFO entries, so after the first host-ring wrap the
+     front-end's GET/PUT became inconsistent and it stopped fetching
+     (`074f493c` fixes the lane depth to 8; the earlier two-client acceptance
+     never wrapped and had masked the regression). The r139 cycle validated
+     the ring fix: the 100-launch soak crossed the host-ring wrap cleanly
+     (`LOOP launches=100 bad=0 STATUS OK`; the previous cycle died at launch
+     8), c1 `victory_mail` is green (60 s), and `smiley` green on a later
+     retry. The residual is an intermittent cold-context/fetched-not-executed
+     launch race (18 failed launches in the cycle: 6 never fetched by the
+     front-end, 12 fetched but not completed by the engine; some later
+     clients intermittently return all-zero results), for which a bounded
+     in-submit retry with a fresh ring entry plus a cold pre-warm is being
+     implemented; the "OK with 0 changed" change-counter is not a reliable
+     execution witness - the client's own `STATUS` is the acceptance signal.
+     Host clean all session, no Xid in the campaign logs, pstore empty, no
+     reboots (in-session PCI function-level reset recovery where needed).
+     ISSUE-0002 (second client in one boot): the sequential case can pass
+     (first two clients green in one cycle; smiley green on retry in the
+     next) but is not yet deterministic; the issue remains open pending
+     repeat-run plus concurrent/simultaneous validation. Active front:
+     the multi-client battery on the physical backend plus launch-latency
+     robustness.
 - **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
@@ -265,6 +308,12 @@ isolation, performance, portability).
      the full FWCLIENT client-managed construct (client ctx buffers + VAS
      mapping + reference promote set), then the server commit. See ADDENDUM
      53/54.
+     **Update 2026-10-14:** this wall moved decisively - the physical GR
+     engine now executes forwarded guest compute launches, and the first two
+     battery clients are green end-to-end on the physical backend (host CUDA
+     bridge disabled). The remaining items are launch-latency robustness (a
+     first launch after an idle can time out and is auto-retried to success)
+     and the third-client chain; see the status update above.
 2. **Hardening the accepted no-claim path.** The first green guest CUDA
    acceptance has landed and is holding; the residual classes are (a) corruption
    via a late first decode behind pump backlog (~3-5% of runs; the experiment
@@ -1583,7 +1632,7 @@ progress.**
 ## Environment
 
 - Host GPU: NVIDIA TU104 (RTX 2080 SUPER Mobile), PCI `10de:1ed3`.
-- Host OS: Ubuntu, kernel 6.8.0-142; the distribution NVIDIA driver manages
+- Host OS: Ubuntu, kernel 6.8.0-146; the distribution NVIDIA driver manages
   the physical GPU; `vgsp.ko` loads as an independent module.
 - Guest: Ubuntu 24.04.5 LTS, stock NVIDIA 570.144 driver, QEMU/KVM q35 with a
   `pcie-root-port` for the vGPU, SeaBIOS, mdev passthrough.