Open-IOV vGPU-IO: host-side GSP emulation for unmodified NVIDIA guest drivers https://git.vgpu.io/open-iov.git/atom?h=m32reorder 2026-10-06T19:18:39+00:00 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-05T18:02:51+00:00 Arthur Hanson Rasmusson arthur@vgpu.io 2026-10-05T18:02:51+00:00 urn:sha1:9575bcb9c69cdf0b166f0ad755f7f75a24bfbba6 Document the corrected GR context-buffer query ABI (80-byte entries, 5136 byte params), the new gsp_phys_rmcall_srv_ctxcommit / gsp_phys_rmcall_channel / gsp_phys_gr_forward parameters, and the live 2026-10-05 findings: PA-only never commits the engine context pointer; on the shared VAS the server pre-books MAIN as managed so a client VA-only promote returns 0x40 at the vaListSetManaged gate; EVICT_CTX does not release it; the external-VAS VA-promote shape wedged the device and must not be repeated. 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. 2026-10-04T20:19:31+00:00 Arthur Hanson Rasmusson arthur@vgpu.io 2026-10-04T20:19:31+00:00 urn:sha1:aa3520f252182aaf64ea0b8856a3ac5e4466ce0e The no-claim emulation path now runs a stock CUDA program end to end: device properties, cudaMalloc, a GPU-authored string kernel read back byte-for-byte, two 4 MB host-to-device copies, a 1 M-element vectorAdd executed on the physical GPU through the host bridge, and the device-to-host copy-back verified element by element. Three consecutive supervised cycles report MAIL + VADD bad=0 checksum=392344090.500000 + STATUS OK with identical input/output hashes. Two data-path correctness fixes make the transfers sound: - Once-only op execution per GPFIFO entry. The pump replays recently consumed ring entries when translation batches are injected so missed releases can land; re-executing a CE copy is not idempotent because its source is a client staging buffer that may have been refilled. Slots now record their raw entry words and a replayed entry matching that identity suppresses operations while still processing releases. - Per-page translation of virtual operands. svc_copy resolved only the first page of a VA range and walked the PA linearly; client staging ranges are frequently split (observed 195 + 61 pages), so the tail of alternating chunks was read from unrelated memory. Multi-page copies now re-resolve each 4 KB page through the trusted resolver. Also carries the earlier uncommitted emulation fixes that got the client to the launch (QMD address-window gate, counter registration persistence, 512 MiB emulated FB, bridge slot hygiene) and bounded diagnostics (sema-bigop, sema-bigcopy, bridge-in/out hashes, daemon INCHECK/OUTCHECK/dumps). 2026-10-03T18:05:38+00:00 Arthur Hanson Rasmusson arthur@vgpu.io 2026-10-03T18:05:38+00:00 urn:sha1:cc79b478843f0230fe6aa8ecd822de7ba71c891e - kernel: gsp_cuda_bridge (QMD launch capture, debugfs job/out/done, param+output resolution cached from inline writes), sema drain fixes (never hold/starve a channel), GR ring autopin + counter autoreg, per-page push reads, counter-derive gate; module builds clean - tools/cuda-bridge: CUDA driver-API daemon executing mail/vadd kernels on the physical GPU, CUBB2/CBD2 v2 protocol, layout check + self-tests - tools/guest-diag + tools/cuda-ab: scanner/pin fixes, victory push-only mode - debug/risc-v-gsp-rm-vm: Phase S simulator wave (GSP device model, boot ladder, triage/re-demo harnesses, docs 30-41), GPGPU-sim scaffolding - STATE-CURRENT/docs updates 2026-10-02T19:45:55+00:00 Arthur Hanson Rasmusson arthur@vgpu.io 2026-10-02T19:45:55+00:00 urn:sha1:680c0ad248dd54f5778808f19fbb6c2f9835ebab - gsp_rm_emulation: dump every guest GPU_PROMOTE_CTX (0x2080012b) params and entries so the real client's promote shape is observable (captured on the emulation path: MAIN 2 MB PA+VA, PATCH, BUNDLE_CB/PAGEPOOL/ATTRIBUTE_CB/ RTV_CB_GLOBAL VA-only, FECS, PRIV, UNRESTRICTED) - gsp_phys_booter: promote mode 19 replays that exact 9-entry shape on the V5 channel with host buffers (MAIN 2 MB + PDB map, small buffers, booking-only VAs); clamp 0..19 - docs/eng-ops: mode-19 result recorded - the server never replied (fn76 -110) and the release fail-safe held WPR2/GPU until an approved reboot; mode 19 is known-wedging 2026-10-02T19:17:34+00:00 Arthur Hanson Rasmusson arthur@vgpu.io 2026-10-02T19:17:34+00:00 urn:sha1:1978df065e52e3068b188554c13fd32434e6cd70 - gsp_phys_booter: mode 18 allocates a FERMI_CONTEXT_SHARE_A (0x9067) on the TSG with the ladder VAS and carries it as hContextShare on the V6 KMD channel, so the share construct can allocate the GraphicsSubcontext the single-MAIN promote needs; clamp 0..18 - docs/eng-ops: GR promote bisection row updated with the session-2 results (modes 12-18: PA-only accepted but no ENG_CTX_VALID; PATCH/PM/FBMEM and server-managed registry all leave the KMD promote at 0x40; wall is the commit/RAMFC path)