Open-IOV vGPU-IO: host-side GSP emulation for unmodified NVIDIA guest drivers https://git.vgpu.io/open-iov.git/atom?h=stallfree 2026-10-18T16:10:03+00:00 2026-10-18T16:10:03+00:00 Arthur Hanson Rasmusson arthur@vgpu.io 2026-10-18T16:09:37+00:00 urn:sha1:7fc3c3ca9f0c2e25c5a932e3fa955dcb0a261ec6 m91-class recap: the first attempt of a mid-sequence forwarded GR launch raises SM warp exceptions ("Illegal Instruction Encoding", "Out Of Range Register") on garbage instruction bytes while a retry of the IDENTICAL QMD and identical shadow content succeeds (r219: fault at +2.5 s, fast re-arm recovered 3 ms later; r223 same pattern). The host retry path only replays the mode-35 lane-enable tail + channel/TSG schedules + doorbell and re-publishes the same method block on a fresh ring entry: no shadow re-copy, no QMD re-read, no cache/TLB invalidate exists anywhere in the ladder. Plain re-submission of byte-identical content flipping the outcome names stale engine-side fetch state at first dispatch, not a content or programming error: the window-0 shadow pool alternates two 8-page banks by submit epoch, so a program VA's bytes change every two launches, and every captured guest QMD carries the QMD v2.3 cache-control word (word 5) with INVALIDATE_INSTRUCTION_CACHE (bit 30) clear - the client driver arms that bit only under its forced-invalidate mode. Two changes: 1. FAULT-CAP (diagnostic, inert until a fault): when a forwarded launch's fault epoch advanced across its window, emit one "vgsp-m91: FAULT-CAP" line per launch (capped at 20 per module-load cycle, then one suppression notice) with: fault-epoch delta, QMD address + first 64 B, live program pair (w48/w49) + resolved engine-visible VA/PA, the first 64 B at that code address, retry decision (fast re-arm / resched/fresh-entry / none) + outcome (ok vs timeout), and the newest relay-decoded 0x1006 note (exceptType/chid/errString). A fault-free launch costs one epoch read and one compare (greens unaffected statically: no prints, no content reads, no engine access). 2. QMD icache invalidate (fix, param-gated default-on gsp_phys_gr_icache_inv=1): set QMD v2.3 word 5 bit 30 in the forwarded QMD (forcing an instruction refetch at dispatch) only when the QMD carries the client driver's standard cache-control signature (word 5 bits 26..29 set) so an unknown QMD revision is never touched; 0 restores the exact pre-change QMD for a one-flip A/B. The bit cannot alter instruction bytes or data - it only invalidates cached fetch state (the same field the client driver sets under forced invalidate) - so green launches keep their semantics; the only cost is a per-launch refetch. Expected next-cycle evidence: zero FAULT-CAP lines with the multi-page client set green confirms the stale-fetch mechanism; any FAULT-CAP content policies the remaining candidates (shadow-VA reuse distance, cross-cycle context state left by killed clients). Doc: 03-architecture/13-vexecution- plane.md m91-class section. (cherry picked from commit 682a5559b1dbbd482d8fe6bdabbc46220ce0d5de) 2026-10-08T18:10:23+00:00 Arthur Hanson Rasmusson arthur@vgpu.io 2026-10-08T18:10:23+00:00 urn:sha1:94352c708442be843950e17e3613dce539ca9fdb The GMMU doc cited pre-a9d29cba lines for the pump, doorbell and svc_sem_write, defined vEP differently from doc 13 (which it names as the vocabulary authority), and called Design A prototypable in the 1.0 programme while M6 classifies the same prototype as post-1.0 research. Fix all three, refresh the status hash, and add the doc to the docs/ and wiki/ indexes with the renumbered reading-order rows. 2026-10-08T18:10:21+00:00 Arthur Hanson Rasmusson arthur@vgpu.io 2026-10-08T18:10:21+00:00 urn:sha1:236e63726c9a99e220d43475aa89ed8c06d719ef Line anchors drifted when a9d29cba landed after the doc was written at 0da66259 (svc_thread, svc_gr_request, svc_pending_add, the H3 guard, the readiness gate). Also: the grv5 SEMA_DBG=Y campaign showed the notifier and event wake-up do fire while the counter slot publication is the link that never writes, so the document's 'completion wake-up' framing was stale in the stage table, section 3.4, section 6.1, the challenges and the iteration plan; refresh the status hash, the discovery-cadence wording and the mode-matrix source note, and extend the change log. 2026-10-08T18:04:47+00:00 Arthur Hanson Rasmusson arthur@vgpu.io 2026-10-08T18:04:47+00:00 urn:sha1:c8ec65aeff12fb6b8bdc2c5028d247f1af6e6fe7 2026-10-08T17:51:22+00:00 Arthur Hanson Rasmusson arthur@vgpu.io 2026-10-08T17:51:22+00:00 urn:sha1:dc551a6bf1458f6a9d621ce97bd86607e38b1080 2026-10-08T17:41:31+00:00 Arthur Hanson Rasmusson arthur@vgpu.io 2026-10-08T17:41:31+00:00 urn:sha1:b7c5212f7691f71202a7c3661993354132429712 2026-10-08T15:52:59+00:00 Arthur Hanson Rasmusson arthur@vgpu.io 2026-10-08T15:52:59+00:00 urn:sha1:e95b4055edbc160e64e2561e32debb220303cf41 Section 3.2 documented 'same style as the kernel module where practical', which the sources contradicted (4-space indentation throughout). It now states the real rules: 4-space/~100-col C, snake_case/_t naming, include guards, status-type error handling, existing set -e/pipefail and SPDX practice. New section 3.4 records conventions that were only implicit: commit-message format with ISSUE-0001 refs, doc Status/change markers, config/ and firmware/ layout, and the per-file SPDX enforcement point. 2026-10-06T23:28:39+00:00 Arthur Hanson Rasmusson arthur@vgpu.io 2026-10-06T23:28:39+00:00 urn:sha1:cd1f2528e8243fed3ce80d5170ef93928e4e7284 rm_capture (chunked decode), launch_audit, state_seed/state_decode, valprobe, rehost, contracts+run_contracts, host_traffic, gmmu_walk, msgq_attach, libos_port, log_decode, server_snapshot; doc index updates in the tool overview, operations pages and the repo README. 2026-10-06T19:18:39+00:00 Arthur Hanson Rasmusson arthur@vgpu.io 2026-10-06T19:18:39+00:00 urn:sha1:6b0673a21b1cb5493554c898181fe289355cadc0 New page docs/04-implementation/03-execution-frontier.md describes the chain that must fire for a guest CUDA launch (guest push -> GPFIFO/front-end -> inline launch-descriptor install -> engine read/dispatch -> completion), where the leading edge is (the descriptor install path), how we know (front-end vs engine-authored observables and their limits), what is exonerated (context validity at dispatch, destination window mapping, fetch alignment, shared-buffer rule, parenting), the ranked issues (verbatim prelude targets, missing descriptor-virtualization control, sentinel hygiene), live investigation lines and labelled theories. Align every page that still said GR execution is blocked on engine-context validity to the current frontier, and add the new page to the README reading order (row 15, later rows renumbered). Docs only; no code. 2026-10-06T00:08:06+00:00 Arthur Hanson Rasmusson arthur@vgpu.io 2026-10-06T00:08:06+00:00 urn:sha1:0ffde4d41eb43e69d8ba7b19780dcf51a8210eb1