wiki: 2026-11-10 afternoon refresh - first real GPU readback; direct-GL/window walls

Refresh STATE-CURRENT, the Main Page and the status/frontier pages: the DDX
3D replay executes and a guest pbuffer glClear+glReadPixels returns a red
pixel (ff0000ff); the RM write-lock holder (Xorg in the DDX scrub wait) is
fixed in df6e71bb. The direct-GL client channel still emits only setup/notify
kicks (ops_runs=0), a window draw wedges X, and X startup/RM stability plus
the DDX 4 GB sysmem allocation remain. Published to open-iov.org.

1 files changed, 40 insertions, 0 deletions

diff --git a/STATE-CURRENT.md b/STATE-CURRENT.md
index 79154d3..7c43dea 100644
--- a/STATE-CURRENT.md
+++ b/STATE-CURRENT.md
@@ -1,5 +1,45 @@
 # Open-IOV Current State
 
+> **Snapshot: 2026-11-10 ~16:45 (SESSION 156 continued; HEAD `df6e71bb`,
+> tree has in-flight kernel/tool work; supersedes the 06:10 entry below).**
+> The **first real GPU readback** landed: a guest
+> `glClear(red)+glFinish+glReadPixels` pbuffer probe returned
+> `rc=0 err=0x0 pixel=ff0000ff` (r1734), with the host logging
+> `section captured` plus `GR LAUNCH submitted` on the DDX channel
+> `0x1000014`. That proves the emulated path can render and read back through
+> the unmodified guest driver. The RM write-lock holder was identified as
+> Xorg in the DDX vidheap scrub wait (NVOS32 `ALLOC_SIZE` 0xa0000, spinning
+> on `vmap+0x6c004`); `df6e71bb` authors the all-ones release pair for a
+> scanner-registered scrub buffer with no USERD GP_PUT, which released the
+> lock and made the readback work.
+>
+> Still open: the direct-GL client channel `0xbfef0002` opens a C597 section
+> but emits only 32/64-byte setup/notify kicks (`ops_runs=0`, `section
+> captured`/`GR LAUNCH` 0) - the GL draws never reach the host. A synchronous
+> window draw wedges X (`xwd -root` writes 0 bytes) while the pbuffer probe
+> works, so screen capture must use the ivshmem frame path. X startup remains
+> a lottery (`Failed to initialize DMA` / push-buffer `0x51` / occasional
+> vmalloc 96 GB) and X can die after forward activity. No non-black screen
+> pixels yet. Milestone position: between M-GL1 and M-GL2; the readback pixel
+> is execution proof, not a screen frame.
+>
+> Walls ranked: (1) direct-GL draw submission/capture on `0xbfef0002`;
+> (2) window/screen present and X stability; (3) X startup/RM degradation
+> (`0x51`); (4) the DDX 4 GB sysmem allocation/OOM (12 GB guest); (5)
+> non-black screen frames and sustained rate.
+>
+> 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 ~42 h (fresh boot 2026-11-08 22:29);
+> `vgsp` loaded + live cycle (QEMU 128357, mdev
+> `c949938a-0391-4aa0-8d49-1679878fe5cd`); `tree` has the campaign's in-flight
+> kernel/tool work (HEAD `df6e71bb`); pstore empty; no reboot during the
+> check.
+>
 > **Snapshot: 2026-11-10 ~06:10 (SESSION 156 continued; HEAD `bb802909`,
 > tree has in-flight kernel work from the campaign; supersedes the 05:30
 > entry below).**