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-12T05:46:11+00:00 2026-10-12T05:46:11+00:00 Arthur Hanson Rasmusson arthur@vgpu.io 2026-10-12T05:38:02+00:00 urn:sha1:8d7409a93ad883a55dbafe057da408f4e334749e Second-client launches scanned a stale/reused guest param page that still held the FIRST client's device VAs: zero new candidates resolved, nothing was relocated, and the engine executed with unrelocated guest pointers (r97 evidence: client#1 '15 candidate ptrs, 100 pages resolved' and win0 param 160=110400; client#2 '12 candidates, 1 page' with 160=75552ec00000 unrelocated). The driver-authored inline param block is captured from the pushbuffer at request time, so scanning it makes pointer discovery independent of guest-page reuse timing. Adds svc_gr_scan_cand()/ svc_gr_scan_inline() and the DIAG win0/guest-param proof line. Client #1 stays green (4 cycles); the remaining second-client stall is the pool semaphore residue (see next commit). 2026-10-12T03:26:27+00:00 Arthur Hanson Rasmusson arthur@vgpu.io 2026-10-12T03:26:27+00:00 urn:sha1:1dab2b18a6b2bed1354c55822d060a539518806b Discriminates engine-side writes of float data (kernel ran with c on this buffer) from non-kernel writes (pointers/QMD-shaped words). 2026-10-12T02:41:26+00:00 Arthur Hanson Rasmusson arthur@vgpu.io 2026-10-12T02:41:26+00:00 urn:sha1:d02b8531472bc6c06e2a231c45ebf5cd3ecb6edd 8 changed pages x 4 passes for smiley vs 33 for victory's vadd - the indexes name the relocated range (bi >= 0x40 = the c-pointer output window 0x150000+) and discriminate engine-side partial dispatch from a guest write-back/read attribution failure. 2026-10-12T02:34:10+00:00 Arthur Hanson Rasmusson arthur@vgpu.io 2026-10-12T02:34:10+00:00 urn:sha1:2d1afd5d04bd61bbea3d63ede5c020684963ca4c r90 evidence: the 3rd session's forwarded launch entered SKED (CWD VALID) and was then saved/unloaded by the FECS before dispatch; qmd_rel stayed at 5/6, GP_GET froze, and every later launch on the boot was never fetched either. The service owns no repair path, so the channel stayed dead until reboot. On the first poll timeout, re-issue the two GPFIFO_SCHEDULE controls the stage-4 sequence used (channel-level 0xa06f0103 + TSG-level 0xa06c0101, both proven accepted) and re-ring the work-submit doorbell, then poll one more full window before the postmortem. No BIND, no PROMOTE (m76-m81 proved the explicit PREEMPT/tail variants stop the QMD enqueuing). 2026-10-12T02:17:15+00:00 Arthur Hanson Rasmusson arthur@vgpu.io 2026-10-12T02:17:15+00:00 urn:sha1:3530fb6ee20d514eddb0e21645abddf512059367 Two fixes and one diagnostic for the all-zero-results class (r89: smiley's 4 vadd launches reported GUEST GR LAUNCH OK yet every output word read 0): - gsp_phys_booter: copy the guest data pages into the bounce window BEFORE gsp_phys_rmcall_publish_locked() rings the doorbell. The fill used to run after the kick; the engine front end starts within ~7 ms, so the kernel could read the window before it was filled. - gsp_phys_booter: per-page checksums at copy-in, compared at copy-out; the copy-out log now reports 'N changed by engine'. An all-unchanged window after a reported completion is the front-end-ran/grid-never- dispatched signature (completion semaphores are front-end authored). The first 3 data (va,hpa,reloc) triples are logged per launch. - gsp_sema_service: svc_gr_data_fill resolves data pages through svc_ipin_lookup() first (guest-truth pins), falling back to svc_resolve_va, mirroring the pool resolver order; a wrong page here silently runs the kernel on zeros. First 16 resolved (va,pa,ap) triples are logged for post-mortem comparison against the guest's own mapping. 2026-10-07T23:53:25+00:00 Arthur Hanson Rasmusson arthur@vgpu.io 2026-10-07T23:53:25+00:00 urn:sha1:effc633f4a1e17f0d12494f6794e5691420eb8dd 2026-10-07T23:45:49+00:00 Arthur Hanson Rasmusson arthur@vgpu.io 2026-10-07T23:45:49+00:00 urn:sha1:d2f142a1d217023fe3e866324a9421f732e9c75f 2026-10-07T23:39:36+00:00 Arthur Hanson Rasmusson arthur@vgpu.io 2026-10-07T23:39:36+00:00 urn:sha1:eeac003d4ea2f8666ad1e2ed088f90163d04238d 2026-10-07T23:25:27+00:00 Arthur Hanson Rasmusson arthur@vgpu.io 2026-10-07T23:25:27+00:00 urn:sha1:8fdd49162dce3abb94d38b20b2df948976cfaf03 2026-10-07T22:53:20+00:00 Arthur Hanson Rasmusson arthur@vgpu.io 2026-10-07T22:53:20+00:00 urn:sha1:ae11886aa97a81e209fb261e5aa4d2d4edfd357a