wiki: 2026-11-10 status refresh - guest GL draws execute on the physical GPU

Refresh STATE-CURRENT, the Main Page and the status/frontier pages: the GSP
event-IRQ fix completes swaps; the 2D path is green end-to-end; the guest's
real GL draws now forward and execute on the physical GPU (work_gr
backend_ok=9); the draw writes 0 pages because its constant-buffer (MVP)
page is unresolved and forced to the seed page; the MME front-end defer, GR
stale-wedge and the X DDX get-word/notifier completion remain. Published to
open-iov.org.

1 files changed, 14 insertions, 15 deletions

diff --git a/wiki/Execution-Frontier.md b/wiki/Execution-Frontier.md
index 658f222..18f150c 100644
--- a/wiki/Execution-Frontier.md
+++ b/wiki/Execution-Frontier.md
@@ -14,7 +14,7 @@
 > [`../docs/04-implementation/03-execution-frontier.md`](../docs/04-implementation/03-execution-frontier.md);
 > the docs tree wins on disagreement.
 
-Status: 2026-11-09, tree `master @ 21e0d611`.
+Status: 2026-11-09, tree `master @ cb8e822b`.
 Tags: `[live]` observed; `[wip]` partial; `[wall]` current blocker; theories
 are labelled as such.
 
@@ -103,13 +103,13 @@ OpenGL 4.6.0 with direct rendering, and the X DDX waits are fixed
 release applied); the direct GL client's GR and CE channels submit and retire,
 and the X DDX kick channel is decoded. GZDoom reached `MAP01` once the DDX
 push-buffer loop was unblocked, but on Mesa llvmpipe — not the emulated vGPU.
-What is missing is **rendered pixels through the NVIDIA path**: forcing GLX
-now selects `libnvidia-glcore`, but the minimal windowed `glxgears` hangs in
-the glcore kick wait (the client polls its per-slot `/dev/nvidia-modeset` fd
-and the guest kernel never signals the event), the DDX push-buffer
-get-word/notifier completion is not implemented, and the direct-GL draws still
-report no physical dispatch; the guest Vulkan pipeline's inline-to-memory
-upload arm remains its gap. The full
+What is missing is **rendered pixels through the NVIDIA path**: the GSP
+event-IRQ fix completes swaps, the 2D path is green end-to-end, and the
+guest's real GL draws now forward and execute on the physical GPU, but the
+draw writes 0 pages because its constant-buffer (MVP) page is unresolved and
+forced to the seed page; the MME front-end defer, the GR stale-wedge and the
+DDX push-buffer get-word/notifier completion remain. The guest Vulkan
+pipeline's inline-to-memory upload arm is its gap. The full
 picture lives on [`Graphics-Execution.md`](Graphics-Execution.md).
 
 No breadth beyond these is claimed: Windows guests, migration and performance
@@ -168,13 +168,12 @@ CUDA guests is in progress.
 
 **Issue D — the graphics pixel frontier.** The display/KMS stack and the GL
 client now run end to end (NvKms registers, X settles, GL 4.6, direct-GL
-channels submit and retire, the X DDX waits are fixed), and forcing GLX
-selects `libnvidia-glcore`; but the minimal windowed `glxgears` hangs in the
-glcore kick wait (the client polls its per-slot `/dev/nvidia-modeset` fd and
-the guest kernel never signals the event), and no rendered (non-black) frame
-has been produced yet. The kernel-visible present completion, the DDX
-get-word/notifier completion and physical dispatch of the GL draws
-(`forwarded=0`) are the named blockers
+channels submit and retire, the X DDX waits are fixed), and the guest's real
+GL draws forward and execute on the physical GPU; but the draw writes 0 pages
+because its constant-buffer (MVP) page is unresolved and forced to the seed
+page, and no rendered (non-black) frame has been produced yet. The constant
+buffer, the MME front-end/stale-wedge stability and the DDX get-word/notifier
+completion are the named blockers
 ([`Graphics-Execution.md`](Graphics-Execution.md)).
 
 ## 6. Lines of investigation (live)