wiki: 2026-11-09 evening refresh 2 - forced GLX reaches glcore; windowed GL waits on kernel kick completion

Refresh STATE-CURRENT, the Main Page and the status/frontier pages: with
SDL_VIDEO_X11_FORCE_EGL=0 the windowed GL path selects libnvidia-glcore,
but the minimal glxgears hangs in the glcore kick wait (poll on the
per-slot /dev/nvidia-modeset fd) while the host completes the beef
notifier memory. The X DDX get-word/notifier completion, the DDX 4 GB
sysmem footprint and physical dispatch of the GL draws remain. Published
to open-iov.org.

1 files changed, 38 insertions, 0 deletions

diff --git a/STATE-CURRENT.md b/STATE-CURRENT.md
index 19661e1..b0b382c 100644
--- a/STATE-CURRENT.md
+++ b/STATE-CURRENT.md
@@ -1,5 +1,43 @@
 # Open-IOV Current State
 
+> **Snapshot: 2026-11-09 ~19:15 (SESSION 156 continued; HEAD `21e0d611`,
+> tree clean; supersedes the 19:05 entry below).**
+> The forced-GLX path moved the renderer wall: with
+> `SDL_VIDEO_X11_FORCE_EGL=0` + OpenGL, GZDoom and glxgears now use
+> `libnvidia-glcore` (the EGL/Mesa fallback is gone). The minimal windowed
+> reproducer (`glxgears`) then hangs in the glcore kick wait: the client polls
+> the per-slot `/dev/nvidia-modeset` fd (`poll(POLLIN, 1 s)`); the host's
+> sweep completes the beef notifier memory (`kick-slot completed
+> h=0xbeef0101 ...`, `client-slot cleared h=0xbeef0100`), but the guest kernel
+> never signals the event the poll waits on. The remaining edge is
+> kernel-visible completion: complete the exact notifier page the guest
+> kernel watches and signal the guest event (the kick-notify executor), not
+> just write the memory. GZDoom's window creation fails/hangs at the same step
+> and can still allocate the DDX's 4 GB sysmem block, which occasionally OOMs
+> the 12 GB guest.
+>
+> Current walls, ranked: (1) the kernel-visible GL present/kick completion
+> above; (2) the X DDX push-buffer get-word/notifier recycle (a diagnostic
+> get-word write released the DDX and let GZDoom reach `MAP01` on llvmpipe
+> earlier, but the kernel lever is not implemented); (3) the DDX's 4 GB
+> sysmem allocation (12 GB guest workaround; suspected emulation gap); (4)
+> the direct-GL draws still report `forwarded=0` - decoded and host-completed,
+> not dispatched to the physical GR engine. No rendered frame through the
+> emulated vGPU yet; the earlier `MAP01` was a llvmpipe datapoint, not the
+> target. Milestone position: between M-GL1 and M-GL2.
+>
+> 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 up 20 h (fresh boot 2026-11-08 22:29);
+> `vgsp` loaded (refcount 0) + mdev
+> `d22c826b-871d-4540-9fc6-63cf3e87f823` + QEMU r1679 live (12 GB guest,
+> glxgears spinning); `nvidia-smi` reports no supported GPU (the vgsp claim
+> is held); pstore empty; no reboot during the check.
+>
 > **Snapshot: 2026-11-09 ~19:05 (SESSION 156 continued; HEAD `e342bd0f`,
 > tree clean, `vgpu/master` in sync; supersedes the 12:45 entry below).**
 > Since the 12:45 entry the campaign closed the X-side execution machinery