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-08T18:10:23+00:00 2026-10-08T18:10:23+00:00 Arthur Hanson Rasmusson arthur@vgpu.io 2026-10-08T18:10:23+00:00 urn:sha1:0ced423a01e85b98fe0d6db7bf7c75300c900316 The GMMU doc cited pre-c33f6006 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:92e45de48d2465594d4619be11b28581020e9eea Line anchors drifted when c33f6006 landed after the doc was written at d0213b5a (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:408f43802c13f1f6aff125d0acb25034fc1f5f73 2026-10-08T17:51:22+00:00 Arthur Hanson Rasmusson arthur@vgpu.io 2026-10-08T17:51:22+00:00 urn:sha1:d4d24b038b13c401b20ae9461f117819bb2f1784 2026-10-08T17:41:31+00:00 Arthur Hanson Rasmusson arthur@vgpu.io 2026-10-08T17:41:31+00:00 urn:sha1:9d1e0cf87df63a2f81c7bb471481336384874861 2026-10-06T19:18:39+00:00 Arthur Hanson Rasmusson arthur@vgpu.io 2026-10-06T19:18:39+00:00 urn:sha1:929646875d80408a21c642ca88ef70efbc0d736a 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:67daa715e22d4b9f130e61486e91bb3705de9fe4 2026-10-05T00:54:03+00:00 Arthur Hanson Rasmusson arthur@vgpu.io 2026-10-05T00:54:03+00:00 urn:sha1:0e073122a56cb2b8498aaacb79968bdf8309b309 The grace-expiry fake path consumed a held CE entry without marking its GPFIFO slot as consumed for the put epoch, and the replay guard only ran while the channel was not deferring. A later pin-batch rewind then re-read the slot, found no recorded identity, and executed the push's copies against a staging buffer the client had refilled after the faked release - a deterministic vadd input shift (a[k] == h_a[k + 2 MB]). - grace-fake consume path now calls svc_replay_note() before advancing; - the svc_replay_seen() replay skip is evaluated unconditionally: a slot consumed in the current epoch is skipped on every replay, deferral or not, until a put wrap clears the mark; - the once-only identity gate gains a content witness (FNV-1a hash of the recorded push bytes): the same entry words with different push content is a new push (clients rewrite push buffers in place) and runs its ops with a cleared done bitmap; suppression requires identical content; - snapshot write-back persists the hash array; new drain counter reident= counts content-mismatch cancellations; - the grace window stays at 8 s: a faked entry's work is never run, so the hold is that work's only chance (a 2.5 s experiment made red-class runs complete with corrupt data instead of timing out). Verified: module 8e90fc7e..., three consecutive end-to-end acceptance runs (MAIL + VADD bad=0 checksum=392344090.500000 + STATUS OK). 2026-10-04T23:13:16+00:00 Arthur Hanson Rasmusson arthur@vgpu.io 2026-10-04T23:13:16+00:00 urn:sha1:15fdbd3d153eedb0d71c4b232ca15bf6a6403d2b A later supervised cycle reproduced the held-entry retry over a refilled staging buffer, the completed operation was skipped, and the end-to-end transfer verified byte-for-byte (bad=0, expected checksum). 2026-10-04T22:54:35+00:00 Arthur Hanson Rasmusson arthur@vgpu.io 2026-10-04T22:54:35+00:00 urn:sha1:2026fa7084b82a64836d946c4bb93d2996961096 The pump's operand-targeted-scan hold decodes a push, runs every op that translates, then leaves the entry pending for a retry. The retry re-decoded the whole push and re-ran the operations that had already completed. A CE copy reads a client staging buffer the client refills per chunk, so the retry overwrote a finished chunk with the following chunk's data (observed: the bridge's vadd input half replaced by the next 1 MB chunk, first half of the device buffer byte-identical to the source shifted by exactly 2 MB; the same 1 MB copy logged twice with different staging contents). The service now records, per GPFIFO slot, the entry identity plus a bitmap of the decoded operation indexes whose work has executed for that identity, and a complete flag for a pass that ended with no operand pending. svc_run_ops skips already-executed ops on a retry and marks the rest as they succeed; the pump stores the record immediately after decode, before any hold path can break, so the pending path can no longer lose it. A replay of a complete identity suppresses all ops; a partial identity retries only what is owed. Also carries the ops_once diagnostic counter in the service snapshot line and documents the operation-granularity rule in the architecture doc.