From 09c68bd214512b3b623c0df96b6a3a4fdd58bd2b Mon Sep 17 00:00:00 2001
From: Arthur Hanson Rasmusson <arthur@vgpu.io>
Date: Mon, 26 Oct 2026 15:48:21 -0400
Subject: docs/04-real-render-walls: SESSION 135b section 15 - every Vulkan CE
 ring latch on record was a stale CUDA block; the ring content is in no
 shadow, no RAM, and not at the PTE target (BAR1 write path verified working;
 client-side write watch is the frontier)

---
 docs/04-implementation/04-real-render-walls.md | 52 ++++++++++++++++++++++++++
 1 file changed, 52 insertions(+)

diff --git a/docs/04-implementation/04-real-render-walls.md b/docs/04-implementation/04-real-render-walls.md
index 82d9cf0..2de379d 100644
--- a/docs/04-implementation/04-real-render-walls.md
+++ b/docs/04-implementation/04-real-render-walls.md
@@ -550,3 +550,55 @@ descriptor wiring (section 8) → non-black frames. 4. Re-run the CUDA
 battery on the fixed module (the r781 boot was a slow-crawl boot; the
 spin stall class is gone) and revisit `sema_gr_xlate`'s multikernel
 forward timeout.
+
+## 15. UPDATE 2026-10-26 (SESSION 135b): every "Vulkan CE ring latch" on record was a STALE CUDA BLOCK - the Vulkan CE ring content has never been observed; the write path is not BAR1 and the content is in no shadow, no RAM, and not at the PTE target
+
+**Forensics on four fresh boots (r782-r786; commits `a674c21c` in tree, `c3cdcf4b` new).**
+
+*The write path works; the driver does not use it for the ring.* A direct
+BAR1 test - the guest writing a known pattern at `BAR1+0x4100000` through
+`/sys/bus/pci/devices/0000:01:00.0/resource1` - lands in the emulated
+vidmem shadow verbatim (`RINGTEST` + `AAAA...` read back by both the guest
+and `sema_vidmem_dump`), so the mdev's BAR1 region path (mmapped, direct
+into `bars[1].vaddr`) is sound at those offsets and at `0x80000`. A
+high-frequency watcher (12 candidate offsets, ~2.5 Hz, including
+`0x80000/0xa0000/.../0x4020000/0x4100000/0x4160000` and the +0x10000
+USERDs) recorded ZERO nonzero dumps across the whole live streaming window
+of a clean Vulkan run (r786; three frames, `VKFRAME_RATE fps=0.05`,
+`VKFRAME_DONE frames=3`, black PPMs). The `shadow_scan` over all three BAR
+shadows (0/1/3) for the CE push header `{0x120,0xb5c50000,...}` and the
+ring-entry pair `{0x20000000,0x2801}` finds nothing, and a byte search of
+the full 4 GB guest-RAM image for both patterns (little-endian, corrected
+from an earlier reversed search) finds nothing either. The walk and the
+learned map resolve the CE ring VA (`0x4100000`) to a guest-RAM page
+(per-boot PA, e.g. `0x135726000`) that reads all zero, and the vidheap
+ioctl log (`PREV149-OUT`) names the channel allocations
+`0x4020000/0x4100000/0x4160000` on every boot - so the ring content is
+written neither to the shadow at its allocation offsets nor anywhere in
+RAM reachable through the guest's own page tables.
+
+*A stale-block trap explains every historical "latch".* On CUDA-first
+boots the capture latched `fb 0x80000 / userd 0x90000` for the Vulkan
+channel `beef0101` with `put=1 get=1` - the dead CUDA client's `caf00012`
+block surviving in VRAM after its session. The decoded entry
+(`va=0x120000000 len=40`) is the old session's (both clients' first CE
+pushes are shape-identical), the expectations seed from the stale pool
+words (`want=2/3` vs `pay=1`; the word page read 3-6), and the Vulkan
+client stalls into its fence timeout (`VKFAIL vkWaitForFences -> 2`) on
+every run. r763's and r781's "auto-pinned ring h=0xbeef0101 -> fb 0x80000"
+rows are the same artefact: both were CUDA-first boots. All genuine
+first-submission latches on record read `put=1 get=0` at the capture
+instant. `c3cdcf4b` rejects a consumed-state candidate (`get == put > 0`)
+in the first-submission capture - a just-submitted entry cannot be
+consumed at the notifier-clear instant.
+
+*The frontier is now precise.* The Vulkan client's CE submissions complete
+only through the fabricated completion machinery (the driver never reads
+its ring back), its CE ring content is invisible to every host source, and
+the GR launch for each frame is held on the unexecuted CE i2m copies
+(`copy pend src=0xdff0d60000 dst=0x50b0000`; walk: src -> vidmem
+`0x570000`, zero). Next: the client-side write watch - find the CPU
+pointer the guest driver writes GPFIFO entries through, its PA via the
+guest pagemap, and why neither the GPU page table target nor any shadow
+holds the result (guest-kernel gdb via the QEMU gdbstub or a kprobe on
+the driver's ring-write helper).
-- 
cgit v1.2.3