open-iov.git/tools/guest-diag/fenceword_assist.py, branch master Open-IOV vGPU-IO: host-side GSP emulation for unmodified NVIDIA guest drivers https://git.vgpu.io/open-iov.git/atom?h=master 2026-10-26T00:17:01+00:00 tools/guest-diag: fenceword_assist.py marked SUPERSEDED (SESSION 126 fence fold, 95e7f57e) - the service now authors the Vulkan fence releases itself via the sema_gr_ahead ring-continuation sweep (r717 evidence: sema-ahead h=0xbeec0100 put=11 swept=10 rels=4 -> sema-svc: deferred release va=0x45ba090 payload=1 (was cur=0) x3, VKFRAME seq/DONE with NO assist); keep as A/B fallback for boots without the fold (sema_gr_ahead=0); evidence in backups/evidence-20261002-victory/r717-fencefold/ (gitignored) 2026-10-26T00:17:01+00:00 Arthur Hanson Rasmusson arthur@vgpu.io 2026-10-26T00:17:01+00:00 urn:sha1:5cebe87c50b871c41608616f9bf196cb998a8e0f tools/guest-diag: fenceword_assist.py - host assist that releases the live vk_frame120 Vulkan fence wait word (session 125): the fence word is the +0x90 slot of the same 16 KB /dev/nvidiactl BO whose +0x80 slot carries the t122 BW init wait word; the assist finds the BO in the client's rw-s mappings (init word 1, fence word 0) and writes 1 to +0x90 per submit. With it, the t122 client reaches VKFRAME seq=1..3/DONE and writes real PPMs to /tmp/vkout (r715: vk-0001..0003.ppm, content still black - the GR shader work is the next gate, not the fence). This tool is the direct predecessor of the service-side fold: the submit push carries an INC-5 group targeting the same slot (observed [2005c017][0x45ba090][0][payload 1][0][0x02100001]) and the service's translation for that VA is correct (verified against the client pagemap), but the group sits in a push region the decoded entry windows do not cover - next: dump the full 11-entry rings and find/cover that entry. 2026-10-25T23:38:26+00:00 open-iov open-iov@localhost 2026-10-25T23:38:26+00:00 urn:sha1:d09be8f621571893c79458bde601894e6fb3f0e1