summaryrefslogtreecommitdiffstats
path: root/docs
Commit message (Collapse)AuthorAge
* vgsp-gr: deliver empty FB fetch pages from real FBMEM, discover the CB per ↵Arthur Hanson Rasmusson3 hours
| | | | | | | | | | | | | | | | | | | | | | | | | | boot, clear the DS latch after each window The active indexed draw's vertex/index buffers resolve through the client's page tables to vidmem pages whose emulated BAR1 shadow is empty (no emulated upload path ever populated it), so the engine fetched zeros and the draw stored nothing. Three delivery paths now cover the page: a real-FB VID leaf for launch fetch pages (QMD pointers, never the data-fill surface) and for vertex streams when every shadow byte is zero; a sysmem-backing copy when the same VA also has a nonzero SYS mapping; otherwise the existing shadow page is used untouched. Render-target pages keep their shadow identity so the copy-out can still ship stores back to the guest. The fixed constant buffer is discovered per boot: the captured SET_MME_SHADOW_SCRATCH(0x18) value is authoritative, the historically observed base is a gated fallback, and a resolved real page is remembered for later misses. The DS HWW ESR latch is now also cleared (W1C) after each replayed window, so a failed window cannot poison the next window's entry state. Validated with three supervised cycles (r1497-r1499): the active streams read the client's real vertex floats, the real MVP resolves, poison stays at 0-1 per run, and the engine clears the render target to opaque black (dump_vidmem 0x200000 = ff000000) with the guest window still all black - the remaining wall is geometry coverage, not data delivery.
* vgsp-gr: keep the validated fixed CB across launches and map each VTG stream ↵Arthur Hanson Rasmusson4 hours
| | | | | | | | | | | | | | | | | | | | | | | contiguously - Remember the last fixed-CB page that resolved through a SYS source and passed the matrix gate; a later resolution miss (or a method-page answer) reuses it instead of zeroing the seed page with the synthetic identity. Only a boot with no validated read ever uses the identity fallback. Do not skip the write on an unchanged hash: the seed page lives in the client's screen allocation and the guest can rewrite it between launches. - Treat the CALL_MME_MACRO(2) vertex stream as one range: map [base,end) into a fresh contiguous fetch line and rewrite both ends from it, preserving the client's stream length across 4 KB boundaries. Unresolvable pages map the module zero page (a zero vertex, never a fault). The generic per-word pass remains the fallback. - Diagnostics: cb-copy logs the first 8 seed-page words and the cached flag; MME-VSTREAM-LINE dumps the resolved base page (client VA, HPA, page count, first 8 words). - Evidence: r1494 (poison 11/17 -> 1/16, real vertex floats at the stream bases, CB cache verified live with src=vaswalk -> src=cached-real) and r1495/r1496 (the active draw's vertex/index page is an all-zero vidmem shadow page while the data exists in guest sysmem - the new wall).
* docs: session-154c - real driver shader images recovered and disassembled ↵Arthur Hanson Rasmusson19 hours
| | | | (PS 384B IPA/MUFU/EXIT, VS 1408/1536B ALD/FFMA transform); with the PS delivered and raw viewport mode 6 the engine writes render-target pages and copy-out pages for the first time (3/900 pages, 1 vidmem page, a few non-black pixels), leaving viewport coverage and guest-side VS delivery
* docs: session-154c - viewport/clip/RT0 closure with driver semantics and the ↵Arthur Hanson Rasmusson21 hours
| | | | shader-crutch finding: the 144-byte vs_hex/ps_hex test image overwrote the client SASS and writes no position; removing it lets real SASS survive but stores remain zero, so the next checks are the VS position/attribute fetch and the client upload path
* docs: session-154c - whole-shadow page-hash bracket proves the no-pixel wall ↵Arthur Hanson Rasmusson24 hours
| | | | is an execution gap (11 launches, zero data pages changed), window decode names the missing viewport family; next = gated viewport prelude
* docs: session-154b - run-bit red herring (completion latch), ↵Arthur Hanson Rasmusson2 days
| | | | sema_gl_sph_bind lever (first slot-34 execution), DS SPH validation wall decode (a2040800/a2040a00, region=0/0) + variant results
* docs: session-154 findings - F1 client-formation protocol, IRAM-gate ↵Arthur Hanson Rasmusson3 days
| | | | regression (gates off restores macro execution), golden+gates-off first engine-final stores
* site: 2026-10-30 wiki refresh - new Project Goals, Performance and ↵Arthur Hanson Rasmusson6 days
| | | | Interfaces and Stability pages; GSP explainer expanded (bare-metal behaviour + the two emulation modes); graphics pages (Graphics Execution, OpenGL, Vulkan, DirectX) with two new diagrams; status refresh across 15 pages; canonical docs updated (README status table, purpose-and-scope, performance contract); published to open-iov.org (67 pages, 0 problems)
* vgsp GL path: widened pin prefixes, ring-scan PROMOTE_CTX ordering evidence, ↵Arthur Hanson Rasmusson8 days
| | | | graphics-execution plan (SESSION 153)
* docs/04-real-render-walls: SESSION 143b section 21 - the Vulkan copy-class ↵Arthur Hanson Rasmusson10 days
| | | | channels are registered/swept/never pushed; no channel carries program bytes or a LAUNCH_DMA; the code page never fills; the refusal path no longer reaches the black-frame baseline (SYNTH-FAULT vs completion ordering)
* docs/04-real-render-walls: SESSION 143 section 20 - the r800 guard holds and ↵Arthur Hanson Rasmusson10 days
| | | | min_data=0 reaches the real engine, which MMU-faults (FAULT_PDE) at the guest program VA; the wall is now the program page's mapping and content (SASS upload), not the data-set gate
* docs/04-real-render-walls: SESSION 140 section 19 - the n_data wiring ↵Arthur Hanson Rasmusson10 days
| | | | (QMD-page note + qmd-ptr seed + pin-aware reads) reaches the launch's data set; the empty-set forward reaches the backend and oopses at gsp_phys_backend_guest_gr_submit+0x4394 - guard first
* docs/04-real-render-walls: SESSION 139 section 18 - 0x43f00000 is the float ↵Arthur Hanson Rasmusson10 days
| | | | 480.0f; the float-shape filter empties the false candidate set; the wall is content (i2m never queued / forward refused first)
* docs/04-real-render-walls: SESSION 138 section 17 - the GR launch wiring ↵Arthur Hanson Rasmusson10 days
| | | | printed (param/prog pages, deduped QMD window, single inline candidate, n_data=0 min 16 refusal); the window content exists in no host-visible source
* docs/04-real-render-walls: SESSION 137 section 16 - the CE-ring hypothesis ↵Arthur Hanson Rasmusson10 days
| | | | for the Vulkan client is disproven by direct write watches (channelFillGpFifo is notrace; the entry store never executes; the client's ring mapping watchpoint catches zero writes); the frontier moves to the GR launch's dstpend/n_data page dependency
* docs/04-real-render-walls: SESSION 135b section 15 - every Vulkan CE ring ↵Arthur Hanson Rasmusson10 days
| | | | latch on record was a stale CUDA block; the ring content is in no shadow, no RAM, and not at the PTE target (BAR1 write path verified working; client-side write watch is the frontier)
* docs/04-real-render-walls: SESSION 134/135 section 14 - the rank-blind ↵Arthur Hanson Rasmusson10 days
| | | | | | | | | | | first-submission capture caused the CUDA stall regression (fixed, a674c21c); the Vulkan CE rings live at 0x4020000/0x4100000/0x4160000 (above the 64 MB capture bound) and the frame chain reduces to the un-latched ring (copy pend -> dstpend -> black) Records the instrument, the regression A/B (r746-era module passes, SESSION 133/134 code spins), the rank-aware fix and its r781 verification, the Vulkan client's actual ring allocations from its own vidheap ioctl log, the failed 4 GB RAM entry search, and the live frame dependency (GR launch inline=8 + copy pend src 0xdff0d60000 -> vidmem 0x570000, dst framebuffer 0x50b0000) with ranked next steps.
* docs/04-real-render-walls: SESSION 133 section 13 - the SASS delivery shape ↵Arthur Hanson Rasmusson10 days
| | | | is FOUND (the driver embeds the program bytes INLINE in a CE LAUNCH_DMA push: in=0x120a00004 -> out=0x205000, 4096 B/run; the Vulkan CE channels carry the same-shaped entries) and the three gates that keep the copies from running are named: the CE ring/USERD boot-lottery (FB convention matched r763 only; the real USERDs sit at 0xfee00/0xff000/0xff200 so the rings are at unaligned offsets like 0xefe00), the VAS age-out vs CE grace race (sema_vas_cand_ms=5000 registers at +5s), and the volatile ring/USERD content that a periodic shadow scan misses; next steps: USERD-shape-derived ring resolution or first-submission latch, then the inline copies and the n_data wiring
* docs/04-real-render-walls: SESSION 132 section 12 - the live utility ring is ↵Arthur Hanson Rasmusson10 days
| | | | PROVEN in guest RAM (walk-confirmed per-run pages 0x11623d000/0x104b55000 with the 14-entry content the sweep decodes; the vidmem 0xa0000 'ring' was a false-positive autopin whose entry0 push reads all-zero and which the pump skipped after 39 rescues); the fixes (dead-entry guard + cross-aperture USERD + per-client util witnesses + op-level copyent) and their verification (r760: ring rc=0 on the live RAM page, live entry reads, VKFRAME_DONE 3 frames); the two LID uploads are the driver's zero buffers by design (256 B zero buffer + 12288 B CE fault buffer) while the GR channel's LID carries the real param bank; the code VA (prog=0xdfd8feb900) maps to a ROTATING code pool (0x62b900 -> 0xc8b000) whose lat entry can go stale and whose pages are empty - the SASS delivery shape (C5C0 0x3800/0x39C8 runs) and the walk-first code-VA resolution are the next two gates
* docs/04-real-render-walls: SESSION 131b section 11 - the A/B that names the ↵Arthur Hanson Rasmusson10 days
| | | | frontier: the CUDA client's uploads fill the emulated vidmem (~450k non-zero dwords across many 1MB blocks) while the Vulkan client's leave only the 14 baseline dwords, so the Vulkan (NVN/GL) upload path is not among the writes the emulation can see; next steps recorded
* docs/04-real-render-walls: SESSION 131 section 10 - the utility ring lives ↵Arthur Hanson Rasmusson10 days
| | | | in vidmem (map PA 0xa0000, live entry 0x120100000/40) and the decoded 14-entry LID ring is a STALE page from a dead session, which is why its payload chunks read zero through every path (four reads + BO poller + gdb write-watchpoint); the CUDA contrast proves the LID arm works with real contiguous payloads; next step is reading the live ring through the map and decoding its entries
* docs/04-real-render-walls: SESSION 130 section 9 - the utility-channel ↵Arthur Hanson Rasmusson10 days
| | | | LOAD_INLINE_DATA arm fires (branch-order fix), the payloads are the driver's zero buffer (four-read proof + full-run BO poller + gdb write-watchpoint), the SASS delivery is the remaining non-black gate (prog page 0x62b000 empty; NVN download path targets the pitch-pool allocation), plus the xlate/util_scan regression bisect result
* docs/04-real-render-walls: SESSION 126 update - the fence fold landed ↵Arthur Hanson Rasmusson11 days
| | | | (sema_gr_ahead sweeps the pre-built GPFIFO continuation beyond GP_PUT and applies the submit pushes' INC-5 RELEASE groups forward-only through the pending ledger; VKFRAME seq/DONE with no host assist) and the compute-dispatch shape decoded: a direct C5C0 method stream (SET_OBJECT + 0x7b4/0x2a4/0x270 windows + 0x3800/0x39C8 code runs + a subchannel-0 data-port stream), NO inline-QMD write, so the existing launch capture/physical forward never fires - the translator that builds the vendor launch from the C5C0 section is the execution gate
* docs: SESSION 66 - the 0x56 pinned to the guest RS alloc path ↵Arthur Hanson Rasmusson12 days
| | | | (rmapiAllocWithSecInfo enters with class 0xc57e, serverAllocResourceUnderLock returns 0x56 before the GSP-RM RPC at under-lock+0x447; _rpcAllocObjectPrologue exonerated); the guest's not-stripped nvidia.ko is a new live-debug instrument; gdb-stub hazards recorded (kill wedges the VM - detach-only recovery; stepi loops wedge the guest - prefer conditional breakpoints)
* docs + nvkmstrace: the GL/Vulkan wall fully bisected (SESSION 65) - ↵Arthur Hanson Rasmusson12 days
| | | | ALLOC_DEVICE reply status 5 (CORE_CHANNEL_ALLOC_FAILED) decoded by the LD_PRELOAD nvKms logger with a widened reply scan; the empty display capability notifier is the first missing piece (a live-gdb fill of SYS_CAP/SYS_CAPB flips the driver to the window path, proving numWindows>0 unblocks it); the residual wall is the vGPU-guest display-class rejection: nvRmApiAlloc(0xc57e) returns NV_ERR_NOT_SUPPORTED inside the guest kernel and never reaches the emulated GSP - the guest runs in vGPU mode where display/modeset classes are host-service-provided by design
* docs: record the real-render walls measured this session (Vulkan ICD ↵Arthur Hanson Rasmusson12 days
| | | | enumerates on the emulated vGPU; vkCreateDevice fails in nvidia-modeset's ALLOC_DEVICE past the new NV0073 head/connector shim, residual wall = the display core/modeset channel objects; Xorg ScreenInit fails in nvidia-push's 10 s channel test with submissions=0 and unresolved X-channel VAs - the guest scanner serves CUDA clients only - plus a rank-0 counter-slot collision with a live CUDA client; EGL/glsi unchanged) and link the page from the README
* docs/vEP: record the r452 copy-out fingerprint rule (a change-detection ↵Arthur Hanson Rasmusson2026-10-22
| | | | fingerprint must not be an algebraic invariant of any plausible kernel operation - the 32-bit additive page checksum was blind to in-place power-of-two scales: 1024 words x 2^23 = 2^33 == 0 mod 2^32; FNV-1a 64 since r452) and the r453 rel_mod=1 default (guest release authored only on the post-copy-out completion edge)
* docs: SESSION 13 handoff (transformer=wedge class, four negative wedge ↵Arthur Hanson Rasmusson2026-10-21
| | | | experiments, the r439 stale-release variant + r441 first-attempt zeroing, r437 battery 10/15, frame animation blocked by the wedge) + frame-sequence tool + LG doc update + transformer stage-bisect tools
* tools/lg + docs: guest frame producer path (CUDA -> ivshmem -> host) and the ↵Arthur Hanson Rasmusson2026-10-21
| | | | | | | | | | | | | | | | | Looking Glass status - tools/cuda-ab/frame_producer.cu: renders an animated Julia frame on the guest GPU and publishes it into the ivshmem BAR (the kvmfr 128 MiB window) with a small header + RGBA payload. - tools/lg/frame_reader.py: host-side reader of /dev/shm/kvmfr-<uuid> that saves each published frame as a PPM (the transport half of the frame path). - tools/guest-diag/egl_frame.c: EGL probe (device/surfaceless/default platforms) - live result: eglQueryDevicesEXT sees the NVIDIA device and eglInitialize succeeds, but eglMakeCurrent fails EGL_BAD_ALLOC (0x3003), the same VASpace-allocation wall as Xorg's 'Failed to allocate VASpace object'. - docs/05-operations/06: the state, the blockers and the exact remaining pieces (guest GL VASpace allocation; LGMP session producer).
* docs: GPUBreach-class audit and threat model for the host write pathsArthur Hanson Rasmusson2026-10-21
| | | | | | | | | | | | | | | | Audit of every host-side write whose target derives from guest data, against the GPUBreach (IEEE S&P 2026) chain: GPU PTE corruption -> arbitrary device read/write -> driver bugs -> CPU root. Findings: the host is structurally off that path (guest GPU page tables host-emulated, physical GPU PTEs host-owned, every write aperture-bounded by vfio_dma_rw to guest RAM or the vidmem shadow, no guest DMA to host buffers), and the remaining wrong-but-valid write class is bounded by the per-page resolution + refusal guards (FILL-TRUNC, FILL-PT-REFUSED, LOWFILL-REFUSED, GRFILL-DROP, stalled-VA demand, sema_copy_dst_pin_guard, DST-DIVERGE). Documents residual risks, what is not claimed (no isolation or side-channel claim; physical Rowhammer is out of scope), and three follow-ups.
* site: 2026-10-20 status refresh - guest CUDA kernel execution workingArthur Hanson Rasmusson2026-10-20
|
* vgsp: m91 - first-fault capture + QMD instruction-cache invalidate for the ↵Arthur Hanson Rasmusson2026-10-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | SM I-fetch lottery 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)
* docs(review): fix GMMU-doc anchors and vEP vocabulary; index docs 13/14 in ↵Arthur Hanson Rasmusson2026-10-08
| | | | | | | | | | | the READMEs 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.
* docs(review): refresh vEP citations against merged master and reconcile GR ↵Arthur Hanson Rasmusson2026-10-08
| | | | | | | | | | | | | completion with FORENSICS-grv5 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.
*-. Merge branches 'docs/vexecution-plane' and 'docs/multi-tenant-gmmu'Arthur Hanson Rasmusson2026-10-08
|\ \
| | * docs(multi-tenant-gmmu): multi-mdev isolation design, GMMU tenant/agent ↵Arthur Hanson Rasmusson2026-10-08
| |/ |/| | | | | paged-attention protection, VRAM oversubscription, portability and M1-M8 roadmap (wiki summary; local provenance in adjacent LOCAL notes)
| * docs(vexecution-plane): add the vGSP Execution Plane architecture doc, wiki ↵Arthur Hanson Rasmusson2026-10-08
|/ | | | deep dive and indexes
* docs/07: state the actual userspace C style; record de facto conventionsArthur Hanson Rasmusson2026-10-08
| | | | | | | | | | 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.
* risc-v-gsp-rm-debugger: land docs 45-53 + harness/sim tool set with testsArthur Hanson Rasmusson2026-10-06
| | | | | | | 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.
* docs: add the GR compute-launch frontier page and align execution status ↵Arthur Hanson Rasmusson2026-10-06
| | | | | | | | | | | | | | | | | | across the tree 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.
* docs: draw the physical-backend lifecycle (init, work, completion, teardown) ↵Arthur Hanson Rasmusson2026-10-05
| | | | on one page
* docs: record GR rung-2 ctx-query ABI fix and the managed-booking wallArthur Hanson Rasmusson2026-10-05
| | | | | | | | | | 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.
* vgsp: never run work for a slot consumed without it (epoch mark + ↵Arthur Hanson Rasmusson2026-10-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | content-hash once gate) 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).
* docs: note live verification of the per-op once gateArthur Hanson Rasmusson2026-10-04
| | | | | | 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).
* vgsp: once-only op execution per entry identity, per-op done bitmapArthur Hanson Rasmusson2026-10-04
| | | | | | | | | | | | | | | | | | | | | | | | | 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.
* vgsp: end-to-end CUDA acceptance in the guestArthur Hanson Rasmusson2026-10-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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).
* vgsp: host CUDA bridge + sema release recovery; greeneye simulator waveArthur Hanson Rasmusson2026-10-03
| | | | | | | | - 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
* kernel: capture the guest's PROMOTE_CTX entries; add promote mode 19 ↵Arthur Hanson Rasmusson2026-10-02
| | | | | | | | | | | | | | | (guest-faithful 9-entry set) - 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
* kernel: GR promote mode 18 (client FERMI_CONTEXT_SHARE_A via hContextShare)Arthur Hanson Rasmusson2026-10-02
| | | | | | | | | | | - 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)
* kernel: GR context-promote bisection modes 4-17 and server-managed-ctxbuf ↵Arthur Hanson Rasmusson2026-10-02
| | | | | | | | | | | | | | | | | | | | registry variant; complete vgsp rename; docs/tooling refresh - gsp_phys_booter: GR promote bisection modes 4-17 (two-phase zero-field VA, batched entries, hVirtMemory, bare VA, KMD SKIP_CTXBUFFER_ALLOC channel, old-interface GPU_INITIALIZE_CTX, FBMEM context buffer, UVM-faithful PA-only, PATCH/PM auxiliary promotes, server-managed no-promote path); PATCH/PM geometry queries and buffers; pre-boot SET_REGISTRY profile selection - gsp_phys_gpu: gsp_phys_rmcall_gr_promote clamp 0..17 and gsp_phys_srv_ctxbuf parameter; registry image variant with RMSetClientRMAllocatedCtxBuffer=0 - vgsp rename across kernel, scripts, tools and docs (module vgsp.ko, /sys/kernel/debug/vgsp/, vgsp-<subsystem>: log prefixes) - risc-v-gsp-rm-debugger user-facing rename and docs/CI refresh; guest-diag tool updates; README/SBOM/install/Makefile sync Live status: CE ladder and P6 guest-copy forwarding green; GR engine context commit still open (all promote shapes accepted or cleanly refused; the channel stays CTXNOTVALID) - see Handoff-vGPU-IO.md Addendum 21 (local).
generated by cgit v1.2.3 (git 2.39.1) at 2026-11-05 23:02:58 +0000