open-iov.git/kernel/gsp_phys_booter.c, branch golden-replayOpen-IOV vGPU-IO: host-side GSP emulation for unmodified NVIDIA guest drivers
https://git.vgpu.io/open-iov.git/atom?h=golden-replay2026-10-06T00:23:44+00:00vgsp: golden9k - size every promoted GR ctx buffer from GET_ENGINE_CONTEXT_PROPERTIES (REAL GR SEM OK)2026-10-06T00:23:44+00:00Arthur Hanson Rasmussonarthur@vgpu.io2026-10-06T00:23:44+00:00urn:sha1:ac3ecc3857efdf5da9dcafeb433dc9af65ae738f
The golden replay promoted 0x1000 placeholders for FECS_EVENT/PRIV/UNR and
1-page VA-only mappings for the four 3D globals; the server's own geometry
reports FECS_EVENT 0x10000, PRIV/UNR 0x80000 each, PAGEPOOL 0x20000,
ATTRIBUTE_CB 0x7d7400 and RTV_CB_GLOBAL 0x80000 on this TU104. The girmap
sizes are wrong for the engine's ctx-init access-map copies and the ctxsw
bundle, producing INJECTED_BUNDLE_ERROR + FECS ctxsw TDR on every VAS shape.
fwclient-mask bit 10 (0x400) sizes every promoted buffer from the server's
GET_ENGINE_CONTEXT_PROPERTIES (0x801707), re-spaces the VAs to per-buffer
caps, extends the ctx small-PT pages to six 2 MB windows and promotes the
real sizes. Result (golden9k2): golden promote status 0, FWCLIENT MAIN
promote status 0, stage 3 complete, REAL GR SEM OK sem=0xc0ffee01
GPGet=1 GPPut=1, clean teardown, no wedge.
vgsp: golden9j - FBMEM backing + VAS mappings for the four 3D global ctx buffers2026-10-06T00:04:05+00:00Arthur Hanson Rasmussonarthur@vgpu.io2026-10-06T00:04:05+00:00urn:sha1:52266aa4c59b1b551862cf26d66134300997fd40vgsp: golden9i - shared-management ladder VAS binding + walker ctx window for the golden channel2026-10-05T23:59:15+00:00Arthur Hanson Rasmussonarthur@vgpu.io2026-10-05T23:59:15+00:00urn:sha1:4da11e8c343576485f99d5981dddbe1ceed62a85vgsp: golden9g - fabricated golden-VAS page-table levels + walker ctx window2026-10-05T23:53:09+00:00Arthur Hanson Rasmussonarthur@vgpu.io2026-10-05T23:53:09+00:00urn:sha1:db7774c297ffd30db7a88ebddcf5d0a2d12c5f33vgsp: golden9f - golden channel on the golden VAS with the client PDB2026-10-05T23:43:20+00:00Arthur Hanson Rasmussonarthur@vgpu.io2026-10-05T23:43:20+00:00urn:sha1:777b962455c9e6e51529a5f056e530a42fc1bd05
The golden9e ctxsw TDR persisted with capture-faithful FBMEM buffers and
mapped VAs. Source dig: the ladder VAS is IS_EXTERNALLY_OWNED, and on that
path the server's promote defers channel-context binding to UVM (which the
ladder never does), so the engine ctxsw never becomes usable. The real
golden channel runs on the PTETABLE_HEAP_MANAGED golden VAS (client-owned
page tables, not externally owned), which takes the full client-managed
commit path. golden9a/b only failed because that VAS had no page directory:
install the ladder root PDB on the golden VAS via DMA_SET_PAGE_DIRECTORY
before the channel alloc, and bind the golden channel to it.
vgsp: golden9e - all ctx buffers FBMEM and every promoted VA PDB-mapped2026-10-05T23:34:47+00:00Arthur Hanson Rasmussonarthur@vgpu.io2026-10-05T23:34:47+00:00urn:sha1:c7f5f7116a2a7e38506cf3c9ea2d5346cc3d681a
The golden9c cycle reached the server context init and then the GR ctxsw
timed out (FECS_A/B TDR) with host-sysmem MAIN/PATCH/FECS/PRIV/UNR and
unmapped promoted VAs; the golden9d FBMEM test ran on a boot left dirty
by golden9c and its 0x1f is not attributable. The real golden wire carried
FBMEM (physAttr=4) for every ctx buffer, so:
- allocate PATCH/FECS/PRIV/UNR as server FBMEM (PATCH sized by the engine
geometry query) in gr_ctx_prepare before the PDB build (mode 25 only);
- map PATCH/FECS/PRIV/UNR at their promoted VAs with VIDMEM PTEs in the
same 2 MB window as MAIN;
- move the FECS/PRIV/UNR and VA-only 3D global VAs into that window and
give the PA-backed entries PHYS_ATTR_FB.
golden9d's FBMEM channel memdescs are kept.
vgsp: golden9d - FBMEM channel memdescs and FBMEM MAIN2026-10-05T22:57:27+00:00Arthur Hanson Rasmussonarthur@vgpu.io2026-10-05T22:57:27+00:00urn:sha1:cfa2a54775396fd732afc36af65624b11d37c095
The golden9c cycle reached the promote commit and hung the GR engine in the
ctxsw wait (FECS_A/B TDR records then a fatal assert). The real golden capture
carried client-local FBMEM instance/USERD/RAMFC/mthd memdescs and FBMEM ctx
buffers; the host-sysmem substitution is the remaining aperture difference.
Allocate one FBMEM block for the four channel memdescs (sliced 0x1000/0x200/
0x1000/0x1000 like the client memmgr) and back the promoted MAIN with the
server FBMEM allocation (VIDMEM physAttr 0x4, VIDMEM PDB leaf PTEs) for mode
25. PATCH/FECS/PRIV/UNR stay host sysmem in this iteration.
vgsp: golden9c - bind golden channel to the ladder's proven VAS2026-10-05T22:29:48+00:00Arthur Hanson Rasmussonarthur@vgpu.io2026-10-05T22:29:48+00:00urn:sha1:e9799396d6a20685a632ddf876d52eb4e127d799
The captured golden VAS cannot be fully constructed by the ladder: its
COPY_SERVER_RESERVED_PDES (0x90f10106) consumes client-RM-reserved page-table
level PAs that only exist in the real client's memmgr (and are boot-specific).
Bind the golden channel to the ladder's own FERMI_VASPACE_A, which already has
server page tables installed by the DMA_SET_PAGE_DIRECTORY + PDB build, so the
pVAS validation in kchannelConstruct_IMPL is satisfied. hObjectBuffer stays 0
(host sysmem PB is client-local) and the USERD keep the proven V5 memdesc
pairing.
vgsp: add golden-replay mode 25 (captured client construct + atomic 9-entry promote)2026-10-05T21:16:18+00:00Arthur Hanson Rasmussonarthur@vgpu.io2026-10-05T21:16:18+00:00urn:sha1:fc8d7923c83c6babd0ee8c23565ac18b709fa5a5
Ladder mode 25 reproduces the real 570.144 host client's golden-image
construct on the golden replay handles: captured channel shape (flags
0x00200320, hObjectBuffer 0, gpFifoOffset 0, gpFifoEntries 0x20,
engineType 1, host memdesc substitutions), a single atomic 9-entry
GPU_PROMOTE_CTX on the golden channel (MAIN id0 and PATCH id2 combined,
ids 3/4/5/6 VA-only globals, ids 9/10/11 FECS/PRIV/UNR combined), then
the TURING_A 3D object. The golden VAS/channel/3D object stay alive and
the existing V6 FWCLIENT promote follows on the golden-initialized
GR-instance state; a failed golden step aborts with no retry and no
follow-up promote. The captured VAS COPY_SERVER_RESERVED_PDES control is
implemented gated (fwclient mask bit 8, zero-level no-op form) because
its level PAs are server-internal. Mode clamp/name/help extended to 25;
modes 1-24 unchanged.
vgsp: fix host crash in FWCLIENT promote order (MAIN first, non-MAIN after)2026-10-05T20:37:50+00:00Arthur Hanson Rasmussonarthur@vgpu.io2026-10-05T20:37:50+00:00urn:sha1:7c4e2defb82c4f9848fb218f88a9f42b6bcea185
The 2026-10-05 16:05 crasher sent an accepted non-MAIN PROMOTE_CTX
(PM/PATCH/FECS/PRIV/UNR) before a MAIN control that failed 0x40; the
writing task then Oopsed in vma_interval_tree_remove with a corrupted
VMA rbtree and module list (host kernel memory corruption).
Restore the reference order (kgrobjGetPromoteIds_FWCLIENT: MAIN first)
and make MAIN-alone the abort point: GPU_INITIALIZE_CTX (mask bit7)
then the single-entry MAIN promote; build and send the non-MAIN entries
only after MAIN commits (or when MAIN is deselected). The previous
accepted-non-MAIN-before-failing-MAIN order is forbidden.
Build is unchanged otherwise; mask 0xbf now reproduces the proven-clean
mask-0x81 shape when MAIN hits the memdesc gate.