summaryrefslogtreecommitdiffstats
path: root/docs/04-implementation/04-real-render-walls.md
diff options
context:
space:
mode:
Diffstat (limited to 'docs/04-implementation/04-real-render-walls.md')
-rw-r--r--docs/04-implementation/04-real-render-walls.md70
1 files changed, 70 insertions, 0 deletions
diff --git a/docs/04-implementation/04-real-render-walls.md b/docs/04-implementation/04-real-render-walls.md
index 6f39803..e02934b 100644
--- a/docs/04-implementation/04-real-render-walls.md
+++ b/docs/04-implementation/04-real-render-walls.md
@@ -761,3 +761,73 @@ program VA in RSI), then re-test `min_data=0` for the no-external-data
launch class: the forward should reach the real engine, and the copy-out
(and the frame copy that already executes) can carry rendered pixels
back.
+
+## 20. UPDATE 2026-10-26 (SESSION 143): THE r800 GUARD HOLDS AND THE `min_data=0` BYPASS REACHES THE REAL ENGINE - IT FETCHES THE PROGRAM AND MMU-FAULTS WITH `FAULT_PDE` AT THE PROGRAM VA; THE WALL IS NOW THE PROGRAM PAGE'S MAPPING AND CONTENT, NOT THE DATA-SET GATE
+
+**The test (r801b).** `gsp_phys_gr_min_data=0` is now an explicit bypass
+(commit `34e611f4`; 0 previously clamped to 1). On a clean cycle
+(module from `34e611f4`, full params, `sema_gr_xlate=1`,
+`sema_gr_util_scan=0`, `sema_vas_cand_ms=5000`, `sema_ce_grace_ms=20000`,
+`sema_ce_hold_ms=0`, `sema_ops_log=8`, `sema_dbg=Y`, `min_data=0`) the
+Vulkan client ran once:
+
+* **No oops.** `grep -c Oops` = 0 for the whole run; the r794
+ `gsp_phys_backend_guest_gr_submit+0x4394` crash class is gone.
+* **The refusal is gone.** Zero `GR submit refused: degenerate data set`
+ lines; the launch is submitted:
+ `GR LAUNCH submitted h=0xbeec0100 ... pages=3 shadow=1
+ qmd_va=0x4b85f00 slot=3 words=239 ... qmdwin=0x108000`.
+* **The engine ran and fetched.** After ~2.5 s:
+ `GR LAUNCH FAILED: timeout after 2500 ms (qmd_rel=0x00000000
+ want=0x600df00d ...)`, and the real firmware reported:
+ `vgsp-fault: func=0x1006 ... errString="Ch 00000001, intr 00000000.
+ MMU Fault: ENGINE GRAPHICS GPC2 GPCCLIENT_GCC faulted @ 0xdf_d8feb000.
+ Fault is of type FAULT_PDE ACCESS_TYPE_VIRT_READ"`.
+* **The copy-out still works:** `sema-gr: copy done h=0xbeec0100
+ push=0x4f4580c dst=0x50b0000 bytes=0x12c000 rows=480 rc=0`.
+* **The client now fails earlier than the black-frame runs:** it reports
+ `VKDEVICE ok family=0` then `VKFAIL vkWaitForFences ... -> 2` and no
+ frame is saved (the service synthesizes a client-visible fault for the
+ failed forward, where the refusal path used to software-complete and
+ let three black frames through).
+
+**The launch wiring measured on this boot.**
+```
+page[0] va=0x4b86000 pa=0x386000 ap=2 qmd_word=32 (param)
+page[1] va=0xdfd8feb000 pa=0x62b000 ap=2 qmd_word=48 (program)
+page[2] va=0x4b85000 pa=0x385000 ap=2 qmd_word=34 (QMD window bank)
+```
+The program page resolves in the emulated vidmem at `0x62b000`, whose
+backing host page (`0x5e0504000`) reads ZERO; `CODEHASH ... h0=0 ...
+SUSPECT (first 16B)` and `FAULT-CAP ... prog_w48=0xd8feb900
+prog_pa=0x5e0504000 code_src=guest-hpa off=0x900 code64=000...` confirm
+the source is empty. The QMD deposit keeps the guest program VA
+(`w48/49=d8feb900 000000df`); in the retry only the `qmd_word 34` page is
+copied to the window-0 shadow (`qmd_word 34 page copied to window-0
+shadow VA=0x1e8000`), so the program pointer is left at the guest VA and
+the engine's page tables have no PDE for it. The post-mortem program
+target reads `slot=30 ... w0..15 = 0`.
+
+**Reading.** The data-set gate and the r800 guard are settled: the
+no-external-data launch is legitimately forwarded and the engine's
+channel/context are alive (it fetched the QMD from the host deposit and
+issued a real MMU fault). The remaining wall is exactly two coupled
+facts:
+1. **Mapping** - the engine's page tables do not map the guest program VA
+ (`FAULT_PDE`), and the host keeps that VA because the code source is
+ an empty page (the shadow rewrite is only used for sources it can
+ trust).
+2. **Content** - the program page is empty in every host-visible source.
+ The driver's program-upload path stages the ucode and copies it to the
+ code heap (the observed CE `LAUNCH_DMA`/inline shape); that copy has
+ not been observed executing for the Vulkan client.
+
+**Next.** (1) Find and execute the Vulkan client's program-upload copy
+(the staging->code-heap CE copy) so the program page becomes non-zero -
+the utility/GR sweeps are the instruments, and the code page becoming
+non-zero is the milestone. (2) Then map/relocate the program VA for the
+engine (or install the PDE) so the fetch succeeds. (3) Then non-black
+frames -> Xorg/GZDOOM -> KVMFR/LG -> CUDA 15/15 + soak -> the 1.0.0
+video -> Windows. Until (1)/(2) land, keep `min_data` at its default 16:
+the bypass forwards a launch the engine cannot complete, which is worse
+for the client than the software-completion fallback.