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

1 files changed, 85 insertions, 17 deletions

diff --git a/STATE-CURRENT.md b/STATE-CURRENT.md
index c73a5a6..7ff44bb 100644
--- a/STATE-CURRENT.md
+++ b/STATE-CURRENT.md
@@ -1,5 +1,69 @@
 # Open-IOV Current State
 
+> **Snapshot: 2026-11-09 ~12:45 (SESSION 156; HEAD `4acc81e8`, tree clean,
+> `vgpu/master` in sync; supersedes the 2026-11-06 ~19:00 entry below).**
+> The graphics front moved from the DS SPH validation gate to a working
+> display/GL stack with one named X-side completion wall. Since 11-06 the
+> 38-commit arc ending at `4acc81e8` landed: the host-side EVO display engine
+> (`035d033c`: core/window/imm channels 0xc57d/0xc57e/0xc57b, NV-DMA push
+> parser, SET_NOTIFIER/UPDATE-FINISHED, raster line) makes the guest display
+> chain real only with `disp_caps_seed=1` (the caps window reads all-zero
+> otherwise -> "Unsupported base display class"); the display instance table
+> is resolved in the guest BAR2 aperture as Linux enumerates it (BAR3) and
+> notifier writes are routed by target (FB shadow vs guest PA);
+> `SET_NOTIFIER_DMA` is `valid=1` and `UPDATE -> FINISHED` is 12/12; lost
+> completion events are force-retried. With that, nvidia-modeset/NvKms
+> register (`/dev/dri/card0` + `renderD128` + `fb0`, `nvidia-smi -L` green),
+> X settles, `glxinfo` reports OpenGL 4.6.0 NVIDIA 570.144 with direct
+> rendering, and GZDoom obtains a real GL context. The approved reboot
+> (2026-11-08 22:29) cleared the stale host GSP-RM state that had wedged
+> every boot in `NV_ESC_RM_VID_HEAP_CONTROL`; post-reboot runs reproduce
+> none of it.
+>
+> The windowed path then exposed and closed three completion walls:
+> (a) the UVM channel-pool tracker - a channel rank N owns pool slot N (the
+> earlier rank+1 model pre-satisfied the next rank and lost the write), the
+> release is fanned through every published VAS translation (the pool page
+> moves between RM-memdesc and VAS-walk pages; `80cbbd04`, `a3060a54`) and
+> the init slot escalates 1..4 (`f10714c9`), so six UVM channels now pass
+> their init waits; (b) the direct-GL GR release - the deferral is scoped to
+> the push's own candidate (a global cross-pass arm let stale candidates
+> defer every later release; `1ad9216a`) and `sema-sw` writes now land for
+> `beef0100`; (c) the direct-GL CE channels `beef0101/0102` - a VRAM-shape
+> USERD scan for the beef CE family (`f2476897`) finds their rings and their
+> submissions retire; the X DDX kick channel `bfef0002` decodes its ring head
+> without a USERD and authors the class-2d notification (`4acc81e8`).
+> Fullscreen GZDoom's mode set still wedges X; the campaign path is a
+> settled X + windowed GZDoom.
+>
+> Honest state: GATE1 still not met - no rendered GZDoom frame and no
+> emulated-vGPU video. Current wall (r1664): Xorg spins ~30-41% CPU in
+> `_nv018351rm` while GZDoom blocks on the X GLX reply
+> (`_xcb_wait_for_reply`) then returns to its glcore spin. The remaining
+> objects are the X RM ioctl behind `_nv018351rm`, the X GLX
+> context-creation completion (direct-GL channel completion vs a display
+> flip notifier), and the GZDoom kick-slot word (not the RM notifier page).
+> Milestone position: between M-GL1 and M-GL2 (the client and display stacks
+> execute; pixels are the gate). Estimate (subjective): a first windowed
+> GZDoom frame hours-to-days if the wall behaves like its predecessors; the
+> two-VM GPU-accelerated video follows after a real frame, with 60 fps/no
+> forcing weeks after that.
+>
+> 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. Watch next: the
+> `_nv018351rm` ioctl identification, the X GLX completion object, and the
+> client kick-slot word - then a rendered windowed GZDoom before any
+> capture.
+>
+> Live at check (read-only): host up 14 h (fresh boot 2026-11-08 22:29);
+> `vgsp` loaded (refcount 0) + mdev
+> `dc0cfb79-fd4e-490a-8f08-e5228caeaed0` + QEMU r1664 live; `nvidia-smi`
+> reports no supported GPU (the vgsp claim is held); pstore empty; no
+> reboot during the check.
+>
 > **Snapshot: 2026-11-06 ~19:00 (SESSION 155 continued; r1562 committed
 > post-reboot; HEAD `2f5b838c`, 1 unpushed; supersedes the ~12:55 entry
 > below).** The DS SPH validation wall narrowed to a single bit this
@@ -330,10 +394,13 @@ unmodified guest graphics client on the emulated vGPU - the graphics ladder
 with motion) -> **M-GL3** (GZDoom GL through the mdev) -> **M-GL4** (60 fps,
 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 execution machinery
-runs (windows, MME macros, the DRAW), and pixels are the gate (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.
+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
+for the 1.0 mission; the CUDA front is backgrounded while the graphics
+campaign holds the device.
 
 **Status.**
 
@@ -832,17 +899,18 @@ front is backgrounded while the graphics campaign holds the device.
    sleeping VFIO mutex taken in atomic context in the sema GMMU walk plus a
    vmalloc fatal exception in the bridge marshal path; reboot recovered the
    host, no Xid.
-5. **Graphics execution (the GL campaign; current top front).** The engine
-   path now executes the direct client's stream (replay windows, MME macros,
-   the DRAW) with engine-authored stores, but three named gates remain:
-   (a) residual per-launch poison classes under the call/window-content
-   lottery (`0x2390` LCB, `0x2080` attr-prelude, `0x1614`; levers built and
-   in flight); (b) the raster/surface-binding blocker - draws retire without
-   storing to the X framebuffer, so render-target/surface binding is the
-   next gate; (c) the present/capture path once (b) lands. GATE1 (a
-   non-black frame with motion) is unmet; the app's FPS numbers are
-   fence-level completion, not rendering. Full context: the 2026-11-04
-   snapshot above and
+5. **Graphics execution (the display/GL campaign; current top front).** The
+   production display and GL stacks now run end-to-end in the guest - the host
+   EVO display engine serves the push-buffer channels, NvKms registers, X
+   settles, `glxinfo` is green and GZDoom obtains a real GL context - and the
+   direct-GL GR/CE channels submit. The remaining gates are: (a) the X RM
+   ioctl behind `_nv018351rm` and the GLX context-creation completion
+   (direct-GL channel completion vs a display flip notifier); (b) the GZDoom
+   kick-slot word (the client polls a kick-slot GPU VA, not the RM notifier
+   page); (c) the raster/present path once (a)-(b) complete. Fullscreen
+   GZDoom's mode set still wedges X; the campaign path is a settled X +
+   windowed GZDoom. GATE1 (a non-black frame with motion) is unmet. Full
+   context: the 2026-11-09 and 2026-11-06 snapshots above and
    [`docs/04-implementation/05-graphics-execution-plan.md`](docs/04-implementation/05-graphics-execution-plan.md).
 
 ## Options to accelerate debugging toward end-to-end CUDA (candidate techniques; not directives)
@@ -997,9 +1065,9 @@ meant to execute on the physical GPU.
 | `cuMemAlloc` + `cuMemcpy` roundtrip (`ALL OK` in the smoke test) | ✅ payload roundtrip verified 64/64 in the guest |
 | Full `nvidia-smi` output / kernel launch | 🟡 the static runtime initializes end-to-end with **real releases**; a full `nvidia-smi` (per-process/utilization) remains unverified |
 | CUDA kernel execution (`vectorAdd`) | ✅ **Guest CUDA executes on the physical GR engine (host bridge disabled, since 2026-10-14):** `victory_mail` `VADD bad=0` + `STATUS OK` and `vecadd_loop` 100 launches PASS; matmul/transformer green after the 2026-10-20 boot-lottery fix (`c72f8948`). Remaining red class: the D2H-stage data classes (release-discipline fixes staged); launch-latency robustness; then battery/soak/multi-tenant breadth. |
-| Graphics execution - OpenGL/X on the emulated vGPU | 🟡 Xorg `:0` + `glxinfo` 4.6.0 (NVIDIA, direct rendering) + GZDoom launch are live; the direct GL client forms channels and submits; the engine executes the client's replay windows, MME macros and the DRAW (slot-34) with engine-authored stores - the first calls-kept draw windows execute (r1529: 44 launches, 0 Class Error, `mac=0x22` x16, 1-2 engine-changed pages per launch) and the DS SPH validation is the last gate before pixels; **no rasterised pixels yet** (every capture black). Ladder position: between M-GL1 and M-GL2. |
+| Graphics execution - OpenGL/X on the emulated vGPU | 🟡 the production display/GL stack now runs: nvidia-modeset/NvKms register (`/dev/dri/card0`, `renderD128`, `fb0`; `nvidia-smi -L`), X settles, `glxinfo` reports 4.6.0 (NVIDIA, direct rendering), GZDoom obtains a real GL context, and the direct-GL GR/CE channels submit (`beef0100/0101/0102`); the UVM channel-pool, GR release-deferral and CE USERD walls are closed. **No rendered frame yet:** the remaining gate is the X RM ioctl/GLX completion (`_nv018351rm`) plus the client kick-slot word; fullscreen GZDoom's mode set still wedges X, so the campaign uses a settled X + windowed GZDoom. Ladder position: between M-GL1 and M-GL2. |
 | Vulkan on the emulated vGPU | 🟡 the guest pipeline renders end-to-end but black; the inline-to-memory upload arm is the named gap; the SESSION 143 fence/completion regression is still open. |
-| Video | 🟡 R18 CUDA-animation video on the emulated vGPU (60/60 frames, exact vs CPU math); two two-VM GZDoom videos (the GPU-accelerated one is the labelled virtio-gpu/virgl path, not the emulated vGPU). |
+| Video | 🟡 R18 CUDA-animation video on the emulated vGPU (60/60 frames, exact vs CPU math); two two-VM GZDoom videos (the GPU-accelerated one is the labelled virtio-gpu/virgl path, not the emulated vGPU); the two-VM GPU-accelerated GZDoom video on the emulated vGPU is not yet produced. |
 | Faults, multi-version, Windows, migration, multi-tenancy, performance | ❌ |
 
 Test status is tracked with the CUDA driver-API smoke test