From 789fd55676beafd5e164e8610417ced8e9e45fba Mon Sep 17 00:00:00 2001 From: Arthur Hanson Rasmusson Date: Sun, 25 Oct 2026 00:53:45 -0400 Subject: docs: SESSION 66 - the 0x56 pinned to the guest RS alloc path (rmapiAllocWithSecInfo enters with class 0xc57e, serverAllocResourceUnderLock returns 0x56 before the GSP-RM RPC at under-lock+0x447; _rpcAllocObjectPrologue exonerated); the guest's not-stripped nvidia.ko is a new live-debug instrument; gdb-stub hazards recorded (kill wedges the VM - detach-only recovery; stepi loops wedge the guest - prefer conditional breakpoints) --- docs/04-implementation/04-real-render-walls.md | 35 +++++++++++++++++++++++++- 1 file changed, 34 insertions(+), 1 deletion(-) (limited to 'docs') diff --git a/docs/04-implementation/04-real-render-walls.md b/docs/04-implementation/04-real-render-walls.md index 7792a2d..f6ea39d 100644 --- a/docs/04-implementation/04-real-render-walls.md +++ b/docs/04-implementation/04-real-render-walls.md @@ -151,4 +151,37 @@ display-engine MMIO/RPC backend the guest expects from its host (the equivalent of NVIDIA's vGPU display plugin), or the specific vGPU configuration that makes the kernel accept the display channel class. Until (b) exists the guest's NVIDIA display path is closed by design, and -GZDOOM-class workloads cannot render on the guest GPU. \ No newline at end of file +GZDOOM-class workloads cannot render on the guest GPU. +## 7. UPDATE 2026-10-25 #2 (SESSION 66): the 0x56 pinned to the RS alloc path + +A new instrument closed the gap: the guest's `nvidia.ko` (DKMS build) is +**not stripped** - copy it out (`/lib/modules//updates/dkms/nvidia.ko`), +`objdump -t`/`-dr` it, compute the module's `.text` runtime base from any +`/proc/kallsyms` symbol, and every guest-kernel function/offset becomes +addressable for live gdb breakpoints on the QEMU stub. With it: + +* `rpcAllocObject_v29_06`/`_rpcAllocObjectPrologue` are **exonerated** for + 0xc57e (their reject list is 0x73/0xc67*/0xc770/0xc77d only; the register + mapping `hClass = r8d` was verified live). +* The failing chain is pinned exactly: `rmapiAllocWithSecInfo` **enters** + with class 0xc57e, calls `serverAllocResourceUnderLock`, and that + function returns **0x56** - *before* the GSP-RM alloc RPC + (`rpcRmApiAlloc_GSP`, called from under-lock+0x447; the emulation never + sees an ALLOC for 0xc57e). The same probe shows 0xc57d/0xc570/0xc573 + return 0. +* So the last blocker for the window path is a **local RS-layer validation + inside `serverAllocResourceUnderLock`** (candidates: the inlined + privilege/class-support checks, `rmapiFixupAllocParams`' per-class fixup, + or `clientAllocResource`'s construct dispatch). The 0x56-producing + instruction is not yet pinned - a `stepi` loop over the QEMU stub is far + too slow and wedged the guest (recovered by a fresh cycle); the next + session should use conditional breakpoints on the function's call-return + sites (the approach in `gdbdiag19` works; the earlier run had truncated + addresses and needs the `0xffffffff00000000` base restored) or a + watchpoint on the status word. + +**gdb-stub field notes**: the stub is single-client; killing an attached +gdb leaves the VM stopped (recover with a detach-only connect); +`stepi` loops over the stub freeze the guest's userspace for minutes - +prefer breakpoints; every probe run with the caps-fill breakpoint changes +the driver's path, so keep the fill in each experiment. -- cgit v1.2.3