STATE-CURRENT: hourly check-back snapshot (2026-11-13 11:12:01)

1 files changed, 65 insertions, 3 deletions

diff --git a/STATE-CURRENT.md b/STATE-CURRENT.md
index 66f9cc7..b73d9b7 100644
--- a/STATE-CURRENT.md
+++ b/STATE-CURRENT.md
@@ -1,5 +1,64 @@
 # Open-IOV Current State
 
+> **Snapshot: 2026-11-13 ~11:10 (SESSION 157 continued; HEAD `436cbf9d` ==
+> `vgpu/master`; working tree carries one in-flight kernel file
+> (`M kernel/gsp_sema_service.c`, eng20 experiment); supersedes the
+> 2026-11-12 ~19:05 entry below).**
+> The graphics front advanced on both sides of the same wall. The **X/DDX
+> stability class is largely closed**: the idle-DMA/ScreenInit wall, the USERD
+> latch lifetime (`13a0c5d6`), the same-pass re-probe thrash (`acb51d53`), the
+> post-ScreenInit Xorg kernel-mode spin (a display-engine GET-past-PUT on a
+> driver ring wrap, `6ebc7cd4`), the flip-event timeout (`770d6b4a`) and the
+> garbage-USERD admission (`b9213c57`) were fixed, and adoption grace plus
+> parking the proven PA (`29690635`) held X green for **>10 minutes** (c195;
+> c198 >2 minutes). What remains is a per-boot **first-generation lottery**:
+> only an X started immediately after boot passes the DDX DMA init (3/7
+> windows in the eng runoff), and later DMA instances can still fail. The
+> **GR forward lane was fixed** (`78225d9c`, the lost per-boot ladder step):
+> captured GL sections now execute on the engine (`GR LAUNCH submitted` /
+> `GUEST GR LAUNCH OK`) and the data-window fix (`579e29b6`) populated it
+> (`n_data` 0 -> 1024). The **engine-zero-write campaign then relocated the
+> store wall**: the replayed 221-word window contains no draw, the front end
+> was parking on a pre-poisoned CWD only as a consequence, and the CWD-clear /
+> CB-parser fixes (`ac741b2a`, `6668e2d0`) landed as hygiene rather than as
+> the cause — the store wall is **upstream in the direct-GL client's push
+> delivery**.
+>
+> **The push-delivery wall is now precisely measured.** The dense-lookalike
+> gate (`7d27df77`) refuses the repeating-pointer page; the live-PA bound was
+> raised from a compile-time 10 GiB to the registered guest-RAM top (14 GiB,
+> `436cbf9d`), so the direct-GL client's 13+ GiB page directory walks and its
+> push bodies decode as **real GR method streams** (`src=4 plausible=1`; e.g.
+> `SET_SUBDEVICE_MASK` + `LAUNCH_DMA`) — reads that were impossible before.
+> The exact remaining gap is registration: the GL setup push (59,556 bytes at
+> VA `0x4001004`) and the draw pushes (`0x4250000`/`0x4250110`) still resolve
+> to zero/implausible PAs, and a walk probe during `gl_frames` shows **no
+> registered VAS maps them** — the payloads live in the client's user/UVM VAS,
+> which the service never registers. Consequently `0 section captured` /
+> `0 CB-DIAG` for `0xbeef0100` on every eng19/eng20 cycle (the X channel
+> `0x1000013` still captures and launches), `gl_frames` remains 5/5 black
+> (`px0=00000000`), and the off-screen mission stays held. Next: register or
+> verify the client user/UVM VAS at the ring latch (`COPY_SERVER_PDES` /
+> `vas_shared`, now that the bound admits 13+ GiB page directories) or pin the
+> payload set from the guest pagemap, then setup push -> C597 stream ->
+> `section captured` -> draws -> wrote/px0 -> mission.
+>
+> CUDA front unchanged (backgrounded while graphics holds the device; its
+> 10-30 status stands): `41343c63` green (`victory_mail` `VADD bad=0` +
+> `STATUS OK`; `vecadd_loop` 100 launches PASS); the fresh-boot battery's
+> red class is D2H-stage with release-discipline fixes staged; the SESSION
+> 143 Vulkan fence regression is not re-measured.
+>
+> Live at check (read-only): host uptime ~16 h (fresh boot 2026-11-12
+> ~19:16); `vgsp` loaded (refcount 0) + mdev
+> `63ba069e-85ae-49c2-894d-f2cb0a3e5edf` + QEMU cycle c307 (PID 126822,
+> 12 GiB file-backed guest, kvmfr ivshmem, since 11:08); `0000:01:00.0` on
+> `open-iov-gsp-phys`; `gl_frames` at ~12 s/frame black; ring `0xbeef0100`
+> mapped by VAS `0xbeef0300` (pdb >13 GiB) with releases decoding, while
+> `0xbeef0101` still misses; `nvidia-smi` reports no GPU (the claim is held);
+> pstore empty; no Xid/Oops; no reboot during the check. The open-iov.org wiki
+> was refreshed alongside this snapshot (11 pages).
+>
 > **Snapshot: 2026-11-12 ~19:05 (SESSION 156 continued; HEAD `800c108f`, one
 > unpushed commit on `master`; working tree clean; supersedes the 2026-11-11
 > ~10:45 entry below).**
@@ -752,9 +811,12 @@ no forcing) -> **M-GL5/M-GL6** (two VMs; video) - with gate definitions in
 [`docs/04-implementation/05-graphics-execution-plan.md`](docs/04-implementation/05-graphics-execution-plan.md).
 The current position is between M-GL1 and M-GL2: the display and GL stacks
 now execute in the guest (NvKms registers, `/dev/dri`, X settles, `glxinfo`
-4.6.0 direct, GZDoom obtains a real GL context) and windowed GZDoom reaches
-renderer startup; the remaining gate is the X RM ioctl / GLX completion path
-before a rendered frame (see the snapshot above). Both objectives are needed
+4.6.0 direct, GZDoom obtains a real GL context), the off-screen GPU frame
+path and the X/DDX stability walls are proven/closed, and captured GL sections
+execute on the engine; the remaining gate is registration of the direct-GL
+payload user/UVM VAS (setup/draw pushes still resolve to zero/implausible
+PAs) plus the window/screen present before a rendered frame (see the snapshot
+above). Both objectives are needed
 for the 1.0 mission; the CUDA front is backgrounded while the graphics
 campaign holds the device.