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-27T17:02:03+00:00 2026-10-27T17:02:03+00:00 Arthur Hanson Rasmusson arthur@vgpu.io 2026-10-27T17:02:03+00:00 urn:sha1:182676755e02238f7a767d1249b4878f7cda0d90 - sema_trace_h + sema-perf logs: per-second channel state (put/last/armed/ counter) and publish-gate reasons, plus maprescue attempt outcomes. Instrument added after window tuning failed to move the 22.4 s/frame glxgears cadence; it located the real blocker in one run. - svc_rescue_push_page: content-verified full-chain map rescue (works for GR channels, whose rescue was previously refused outright). - gsp_phys_booter: RPC reply waits now usleep_range(150-350us) instead of msleep(5) (termbin review suggestion, in-tree constant verified; no FPS change measured, kept as correctness-neutral latency reduction). Evidence: r843-r847 dmesg_live logs; measured constant 22.4 s/frame for glxgears across all param windows (grace/poll/first-poll), showing the pacer is elsewhere - traced to client pushbuffer pages (va=0x3f06270-class) failing svc_lookup (-ENOENT) while the client is alive. 2026-10-27T11:06:12+00:00 Arthur Hanson Rasmusson arthur@vgpu.io 2026-10-27T11:06:12+00:00 urn:sha1:38ba1e2d7d579c2467dfa10daca16cdbd6579089 Every RM client maps different objects at the same numeric VAs (all clients' windows sit at 0x1200xxxxx), so the global VA-keyed pin/lat/map layers conflate them across clients. Live walk_probe evidence (r834): the X server's ring VA 0x120090000 resolved through the GL client's page tables (vas h=0xcaf00005 -> a zero page) while the X client's own VAS (vas h=0x10005) holds the real page (pa=0x1294fa000). That conflation is what wedged the X server's readback wait and starved the RC watchdog's ring (its pushes decoded as empty). * Parse NV_CHANNEL_ALLOC_PARAMS.hVASpace (@28; layout confirmed by the struct's own known offsets) at channel registration and carry it on svc_channel. * svc_chanvas_lookup: resolve a VA through the serviced channel's own VAS page tables first (svc_cur_vas, refreshed per channel turn and in the decode path). The hook sits at the head of svc_lookup_trusted, so ring, push, release and notifier resolution all inherit it; a failed walk falls through to the old chain unchanged. Live r835: X's XShmGetImage readback, previously never completing, returned after its long wait and a frame reached the kvmfr BAR (first frame content still black and readback latency still ~87 s; the guest-side fbcopy_pub framebuffer reader tool is added for the direct-VRAM capture path, find/pub/test modes).