summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAge
* vgsp: golden9k - size every promoted GR ctx buffer from ↵golden-replayArthur Hanson Rasmusson6 days
| | | | | | | | | | | | | | | | | | GET_ENGINE_CONTEXT_PROPERTIES (REAL GR SEM OK) The golden replay promoted 0x1000 placeholders for FECS_EVENT/PRIV/UNR and 1-page VA-only mappings for the four 3D globals; the server's own geometry reports FECS_EVENT 0x10000, PRIV/UNR 0x80000 each, PAGEPOOL 0x20000, ATTRIBUTE_CB 0x7d7400 and RTV_CB_GLOBAL 0x80000 on this TU104. The girmap sizes are wrong for the engine's ctx-init access-map copies and the ctxsw bundle, producing INJECTED_BUNDLE_ERROR + FECS ctxsw TDR on every VAS shape. fwclient-mask bit 10 (0x400) sizes every promoted buffer from the server's GET_ENGINE_CONTEXT_PROPERTIES (0x801707), re-spaces the VAs to per-buffer caps, extends the ctx small-PT pages to six 2 MB windows and promotes the real sizes. Result (golden9k2): golden promote status 0, FWCLIENT MAIN promote status 0, stage 3 complete, REAL GR SEM OK sem=0xc0ffee01 GPGet=1 GPPut=1, clean teardown, no wedge.
* vgsp: golden9j - FBMEM backing + VAS mappings for the four 3D global ctx buffersArthur Hanson Rasmusson6 days
|
* vgsp: golden9i - shared-management ladder VAS binding + walker ctx window ↵Arthur Hanson Rasmusson6 days
| | | | for the golden channel
* vgsp: golden9g - fabricated golden-VAS page-table levels + walker ctx windowArthur Hanson Rasmusson6 days
|
* vgsp: golden9f - golden channel on the golden VAS with the client PDBArthur Hanson Rasmusson6 days
| | | | | | | | | | | | The golden9e ctxsw TDR persisted with capture-faithful FBMEM buffers and mapped VAs. Source dig: the ladder VAS is IS_EXTERNALLY_OWNED, and on that path the server's promote defers channel-context binding to UVM (which the ladder never does), so the engine ctxsw never becomes usable. The real golden channel runs on the PTETABLE_HEAP_MANAGED golden VAS (client-owned page tables, not externally owned), which takes the full client-managed commit path. golden9a/b only failed because that VAS had no page directory: install the ladder root PDB on the golden VAS via DMA_SET_PAGE_DIRECTORY before the channel alloc, and bind the golden channel to it.
* vgsp: golden9e - all ctx buffers FBMEM and every promoted VA PDB-mappedArthur Hanson Rasmusson6 days
| | | | | | | | | | | | | | | The golden9c cycle reached the server context init and then the GR ctxsw timed out (FECS_A/B TDR) with host-sysmem MAIN/PATCH/FECS/PRIV/UNR and unmapped promoted VAs; the golden9d FBMEM test ran on a boot left dirty by golden9c and its 0x1f is not attributable. The real golden wire carried FBMEM (physAttr=4) for every ctx buffer, so: - allocate PATCH/FECS/PRIV/UNR as server FBMEM (PATCH sized by the engine geometry query) in gr_ctx_prepare before the PDB build (mode 25 only); - map PATCH/FECS/PRIV/UNR at their promoted VAs with VIDMEM PTEs in the same 2 MB window as MAIN; - move the FECS/PRIV/UNR and VA-only 3D global VAs into that window and give the PA-backed entries PHYS_ATTR_FB. golden9d's FBMEM channel memdescs are kept.
* vgsp: golden9d - FBMEM channel memdescs and FBMEM MAINArthur Hanson Rasmusson6 days
| | | | | | | | | | | The golden9c cycle reached the promote commit and hung the GR engine in the ctxsw wait (FECS_A/B TDR records then a fatal assert). The real golden capture carried client-local FBMEM instance/USERD/RAMFC/mthd memdescs and FBMEM ctx buffers; the host-sysmem substitution is the remaining aperture difference. Allocate one FBMEM block for the four channel memdescs (sliced 0x1000/0x200/ 0x1000/0x1000 like the client memmgr) and back the promoted MAIN with the server FBMEM allocation (VIDMEM physAttr 0x4, VIDMEM PDB leaf PTEs) for mode 25. PATCH/FECS/PRIV/UNR stay host sysmem in this iteration.
* vgsp: golden9c - bind golden channel to the ladder's proven VASArthur Hanson Rasmusson6 days
| | | | | | | | | | | The captured golden VAS cannot be fully constructed by the ladder: its COPY_SERVER_RESERVED_PDES (0x90f10106) consumes client-RM-reserved page-table level PAs that only exist in the real client's memmgr (and are boot-specific). Bind the golden channel to the ladder's own FERMI_VASPACE_A, which already has server page tables installed by the DMA_SET_PAGE_DIRECTORY + PDB build, so the pVAS validation in kchannelConstruct_IMPL is satisfied. hObjectBuffer stays 0 (host sysmem PB is client-local) and the USERD keep the proven V5 memdesc pairing.
* vgsp: add golden-replay mode 25 (captured client construct + atomic 9-entry ↵Arthur Hanson Rasmusson6 days
| | | | | | | | | | | | | | | | | | promote) Ladder mode 25 reproduces the real 570.144 host client's golden-image construct on the golden replay handles: captured channel shape (flags 0x00200320, hObjectBuffer 0, gpFifoOffset 0, gpFifoEntries 0x20, engineType 1, host memdesc substitutions), a single atomic 9-entry GPU_PROMOTE_CTX on the golden channel (MAIN id0 and PATCH id2 combined, ids 3/4/5/6 VA-only globals, ids 9/10/11 FECS/PRIV/UNR combined), then the TURING_A 3D object. The golden VAS/channel/3D object stay alive and the existing V6 FWCLIENT promote follows on the golden-initialized GR-instance state; a failed golden step aborts with no retry and no follow-up promote. The captured VAS COPY_SERVER_RESERVED_PDES control is implemented gated (fwclient mask bit 8, zero-level no-op form) because its level PAs are server-internal. Mode clamp/name/help extended to 25; modes 1-24 unchanged.
* vgsp: fix host crash in FWCLIENT promote order (MAIN first, non-MAIN after)Arthur Hanson Rasmusson6 days
| | | | | | | | | | | | | | | | The 2026-10-05 16:05 crasher sent an accepted non-MAIN PROMOTE_CTX (PM/PATCH/FECS/PRIV/UNR) before a MAIN control that failed 0x40; the writing task then Oopsed in vma_interval_tree_remove with a corrupted VMA rbtree and module list (host kernel memory corruption). Restore the reference order (kgrobjGetPromoteIds_FWCLIENT: MAIN first) and make MAIN-alone the abort point: GPU_INITIALIZE_CTX (mask bit7) then the single-entry MAIN promote; build and send the non-MAIN entries only after MAIN commits (or when MAIN is deselected). The previous accepted-non-MAIN-before-failing-MAIN order is forbidden. Build is unchanged otherwise; mask 0xbf now reproduces the proven-clean mask-0x81 shape when MAIN hits the memdesc gate.
* vgsp: FWCLIENT entry-selection mask and golden-replay hardeningArthur Hanson Rasmusson6 days
| | | | | | | | | | | | - gsp_phys_rmcall_fwclient_mask (default 0x3f): per-entry selection for the mode-24 FWCLIENT promote set; bit6 selects the MAIN UVM VA-only shape. - golden replay: tolerate the client-local system-memory PB step and continue with hObjectBuffer=0; on-ladder TURING_A 3D object retained best-effort. Live bisection on the KMD channel: MAIN alone reaches the per-buffer commit and stops at the engine-context memdesc state; PM-only and PATCH-only are accepted; any multi-entry control containing MAIN is refused 0x1f. All cycles release clean.
* STATE-CURRENT: 16:00 snapshot (GR golden replay, mode 24, FLR recovery)Arthur Hanson Rasmusson6 days
|
* vgsp: GR golden-replay groundwork and FWCLIENT promote mode 24Arthur Hanson Rasmusson6 days
| | | | | | | | | | | | | | | | | | - golden replay (gsp_phys_rmcall_golden, default off): replay the stock client's post-load golden channel allocations (separate VAS, pushbuffer objects, USERD, bare GR channel, TURING_A 3D object) before the ladder channel; best-effort: a failure warns and the ladder continues. - on-ladder TURING_A (0xc597) 3D object allocation before the compute object (best-effort) to initialize server-side GR-instance state. - promote mode 24: the reference FWCLIENT non-3D set (MAIN, PM, PATCH, FECS_EVENT, PRIV_ACCESS_MAP, UNRESTRICTED_PRIV_ACCESS_MAP) as one GPU_PROMOTE_CTX on the KMD channel, with per-entry logging and explicit omission semantics; mode clamps/descriptions extended to 24. Live: mode 23 soft-stops 0x1f on the server-managed shared channel and reaches the per-buffer commit on the KMD channel, where it stops at the missing engine-context memdesc; mode 24 emits all six entries and is refused with 0x1f before BIND. All cycles release clean, GPU green.
* STATE-CURRENT: 15:05 check-back snapshot (GR rung-2, mode 23 soft-stop, ↵Arthur Hanson Rasmusson6 days
| | | | per-type VRAM live)
* vgsp: GR promote mode 23 (hVirtMemory FBMEM server-managed commit shape)Arthur Hanson Rasmusson6 days
| | | | The hVirtMemory no-entry promote backed by the server-owned FBMEM context object (GSP_RM_ALLOC class 0x40) on the server-managed shared V5 channel. A physical memdesc bypasses the server-booked engine-ctx vaList and hands the memdesc straight to the per-buffer commit 0x5b00d2c, the one remaining promote shape on the stable shared+srvctx path. Runs grv23/grv23v6 soft-stop at PROMOTE_CTX hVirtMemory status=0x1f before BIND with clean releases.
* vgsp: srv_ctxcommit mode 2 (V6 client combined init+VA entry)Arthur Hanson Rasmusson7 days
| | | | | | | | | Make gsp_phys_rmcall_srv_ctxcommit an int mode: 1 (default) = map + INITIALIZE_CTX + UVM-shape VA-only promote; 2 = V6 client variant, no INITIALIZE_CTX and one combined PA+VA MAIN entry with bInitialize=1 and bNonmapped=0 so the first ctxsw initializes from the golden image; 0 = pure server-managed. Lets the next supervised cycle bisect both entry shapes without a rebuild. Build clean; not hardware-tested (GPU wedged).
* docs: record GR rung-2 ctx-query ABI fix and the managed-booking wallArthur Hanson Rasmusson7 days
| | | | | | | | | | 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: V6 client-owned ctx-buffer VA commit path (srvctx)Arthur Hanson Rasmusson7 days
| | | | | | | | | | | | Source-confirmed: with the SKIP_CTXBUFFER_ALLOC channel flag the server does not allocate MAIN, does not map/book it, and its internal init/promote helpers return early for KMD virtual contexts. The client therefore owns the buffer. When no server MAIN is reported on a V6 channel, map the prepared client MAIN at the ladder ctx VA (sysmem PTEs), send GPU_INITIALIZE_CTX to install the memdesc, then the UVM-shape VA-only promote; with no server pre-booking the vaListSetManaged gate should pass and the per-buffer commit program the engine context pointer. V5 keeps the historical PA-only fallback. Build clean; not hardware-tested (GPU wedged).
* vgsp: GR forwarding static-review fixes (GR/CE slot bit, release VA->PA, ↵Arthur Hanson Rasmusson7 days
| | | | | | | | | | | | | | | | | | | | | | shadow refusal) Five defects found in a static review of the default-off GR forwarding path (no hardware test possible; GPU wedged): - clear the shared request slot's GR mode bit when a CE request is filled, so a prior GR request can never make a later CE push run the GR work function with stale fields; - resolve the QMD release0 guest VA to a guest PA on the service thread (counter pin/derive, else the trusted resolver) and only convert PA->HPA in the work item; the previous code fed the VA to the PA-based translator and would write release0 into an unrelated guest page; - take the refusal path (goto gr_page_unmapped) on every Tier-2 shadow failure instead of continuing to submit a half-built method stream; - consume the QMD run on replay passes when the GR forward is enabled so replayed QMD words are never reinterpreted as CE method headers; - only queue a captured GR candidate against the channel that captured it. Build clean (make -C kernel, W=1 only pre-existing warnings).
* vgsp: guest GR forwarding backend and capture (gsp_phys_gr_forward, default off)Arthur Hanson Rasmusson7 days
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add a default-off guest GR (compute) forwarding path so a guest CUDA launch submitted on its GR channel can be executed by the physical GR engine on the ladder channel, with fail-closed fallback to the host CUDA bridge and the unchanged software release path. - New module parameter gsp_phys_gr_forward (default 0) and accessor. - New GR execution gate: boot_stage.rmcall_gr_exec_ok, latched only after a real GR submission logs REAL GR SEM OK; the backend refuses while it is unset. - Sema capture: a completed 64-word inline QMD on a trusted, non-replay GR decode becomes an svc_gr_cand (push identity, decoded release0, parameter/program/pointer fields, up to 8 captured inline-write records); the CUDA bridge stays authoritative while the parameter is off and is reached in order forward -> bridge -> software release. - Backend: gsp_phys_backend_guest_gr_submit() maps pages at their own guest VAs through fresh Tier-1 small-PT pages/PDE installs or relocates inline-captured pages to ladder shadow pages (Tier 2), builds SET_OBJECT + the inline-QMD method run + REPORT_SEMAPHORE on the compute subchannel, reuses the shared GPFIFO/USERD/doorbell publish tail (extracted from the CE submit path, CE bytes unchanged) and polls the QMD release and/or module semaphore, draining the epoch-gated fault queue on timeout. - Sema wiring: GR requests reuse the INFLIGHT/hold/deferral machinery so the guest channel release applies only on the submit's success/failure edge; hold shims preserve the channel engine type. - Counters and a work_gr state line plus a stats accessor. - Bounds are fixed: 16 pages, 8 inline records, 64 QMD words; every pointer/size checked, pool exhaustion and stale mappings fail closed. - New ABI layouts pinned with static_asserts. Compile-only change: no device test performed. (cherry picked from commit ae507e6f241c7e3498728f9d1ffc2d41ede5cd64)
* vgsp: add gsp_phys_rmcall_channel to force one GR channel variantArthur Hanson Rasmusson7 days
| | | | | | | | | | Lets a bisection pair any promote shape with any channel shape, in particular V6 (SKIP_CTXBUFFER_ALLOC, KMD-managed) with the server-managed VA-only promote: with skip-ctxbuffer the server's kgrctxMapCtxBuffers does not pre-book the engine context vaList, so the VA branch's vaListSetManaged(NV_FALSE) gate should pass and the per-buffer commit can program the engine context VA. Default 0 keeps the mode-selected walk byte-identical. Not hardware-tested (GPU wedged; see Handoff ADDENDUM 51).
* vgsp: GR server-managed context commit experiments (EVICT, VA promote, ↵Arthur Hanson Rasmusson7 days
| | | | | | | | | | | | | | | | | | | | | | | | | external path) Rung-2 bisection after the GET_CTX_BUFFER_INFO ABI fix made the server ctx geometry visible (8 buffers; MAIN 0x133000 FBMEM, PATCH 0x5000): - map the server MAIN/PATCH at the ladder ctx VAs with FBMEM PTEs and send the UVM-shape VA-only promote (bInitialize=0, bNonmapped=0). On the shared VAS the per-entry VA branch calls vaListSetManaged(NV_FALSE) and returns 0x40 because the server pre-booked MAIN as managed; EVICT_CTX (status 0) does not release that booking. - try the same VA promote on the external VAS where the server did not book (kgrctxMapCtxBuffers early-returns): the promote never replies (-110) and leaves the device in the locked fail-safe (WPR2 up, unbound). Do not repeat this shape without a new hypothesis. - FBMEM physAttr selection for the server MAIN fixed (aperture 2 -> 0x4); gsp_phys_rmcall_srv_ctxcommit parameter added (0 = pure server-managed, no client promote). - query prints all 16 entries and records PATCH; query ABI 80-B/5136. Hardware state after the external-VAS run: GPU wedged, reboot required (no automated reboot). All shapes stay default-off behind gr_promote=17 + gsp_phys_srv_ctxbuf.
* vgsp: GR ctx query ABI fix, server-managed ctx map exclusion, raw diag captureArthur Hanson Rasmusson7 days
| | | | | | | | | | | | | | | | - NV2080_CTRL_GR_CTX_BUFFER_INFO is 80 bytes (NvBool is NvU8: flags at 56..59, uuid at 60) and the params are 5136 bytes, not 5648; the previous ABI mismatch is why GR_GET_CTX_BUFFER_INFO returned NV_ERR_INVALID_ARGUMENT (0x1f) on every shared-VAS cycle. - Under gsp_phys_srv_ctxbuf the GSP-RM server allocates/maps/commits the engine context itself: do not install the client GR context-window PDEs and do not map the client ctx VA in the PDB, so a client mapping cannot clobber the server's own context-window page table. - Dump the server-written INSTANCE/RAMFC chunks after BIND/SCHEDULE on the shared GR path so the committed engine-context pointer/VA can be located. - Emit the full NOCAT diag buffer as 16-byte hex rows (the printable copy is capped at 192 dotted bytes and hides binary fault dumps). Untested on hardware at commit time; the next supervised GR cycle validates.
* vgsp: fix per-type VRAM type lookup and canonical FB-size encodingArthur Hanson Rasmusson7 days
| | | | | | | | | | | | | | | | | The 708a3802 per-type VRAM change stripped an nvidia- prefix from mdev->type->sysfs_name, but sysfs_name is the registered type name verbatim; the mdev core only prefixes the type DIRECTORY with the parent driver string. Every lookup failed, so all mdevs silently fell back to 512 MiB, nvidia-vgpu-turing-1g was unreachable and available_instances capped at 1. Match sysfs_name directly in get_available, show_description and mdev_create. Also canonicalise the NV_PFB_PRI_MMU_LOCAL_MEMORY_RANGE encoder (BAR0+0x100ce0) by stripping factors of two from MAG so 512 MiB encodes 0x19 again (1 GiB 0x1a, 2 GiB 0x1b) instead of the non-canonical 0x204. Default-512M behaviour is now byte-equivalent to the known-good pre-VRAM module except max_instances=2. Module sha256 cb1724d3.
* vgsp: per-mdev emulated VRAM size (1.0 multiple mediate sizes)Arthur Hanson Rasmusson7 days
| | | | | | | | | | | | - nv_vgpu_type_info/ioctl gain vram_mb; nv_vgpu_device gains fb_emul_size bound from the mdev type at create (default 512 MiB). - New nvidia-vgpu-turing-1g type (1024 MiB); turing max_instances 1 -> 2; show_description reports the per-type framebuffer and max_instance. - Thread fb_emul_size through GSCI fb_length/region/frtsOffset, WPR2, NV_PFB_PRI_MMU_LOCAL_MEMORY_RANGE, the vidmem allocator bound and the BAR1 shadow; bar_info callback uses the per-device size. - UNTESTED at commit time: builds clean; validation blocked by the Xid 140 incident (reboot pending). See Handoff-vGPU-IO.md ADDENDUM 48.
* vgsp: GR shared path ctx-window PDE install and PATCH+MAIN PA-only promote ↵Arthur Hanson Rasmusson7 days
| | | | | | | | | | | fallback - UPDATE_PDE_2 now also installs the GR context window PT pages (PDE 17+). - The shared-path fallback promotes PATCH then MAIN PA-only (mode-13 order, the real client's set); the mapped (bNonmapped=0) entry still hits the known 0x40 structural gate and is not sent. - Shared+srvctx: channel/BIND/schedule/token/GPFIFO fetch all green; the remaining failure is ROBUST_CHANNEL_GR_FAULT_DURING_CTXSW (0x2c).
* STATE-CURRENT: 12:16 check-back snapshot (GR stage-4 frontier: PBDMA fetches ↵Arthur Hanson Rasmusson7 days
| | | | GPGet=1, ctxsw fault 0x2c; 10 clean no-wedge cycles; GR fixes committed)
* vgsp: GR ladder shared-VAS page-table install and server-managed ctx commit pathArthur Hanson Rasmusson7 days
| | | | | | | | | | | | | | | | - DMA_UPDATE_PDE_2 client control installs the ladder leaf PT through the server's own MMU walker on the shared-management VAS (the raw-PDB entries are not preserved by the root migration); FLUSH_PDE_CACHE + post-install refill + PT diagnostics. - srvctx registry profile also disables split VAS management; MAP_MEMORY_DMA is not served by GSP-RM for this client (NV_ERR_INVALID_FUNCTION), so the PDE control replaces it. - shared-path context commit helper: GPU_INITIALIZE_CTX + PA-only GPU_PROMOTE_CTX for the server-reported (or client fallback) MAIN buffer; GR_GET_CTX_BUFFER_INFO sends bufferCount=64. - Result: shared VAS + srvctx no longer wedges; channel/BIND/schedule/token green, PBDMA fetches the GPFIFO (GPGet=1); remaining wall is ROBUST_CHANNEL_GR_FAULT_DURING_CTXSW (0x2c).
* STATE-CURRENT: hourly check-back snapshot (2026-10-05 12:12:01)Arthur Hanson Rasmusson7 days
|
* STATE-CURRENT: 10:38 check-back snapshot (campaign 239-242 green; 243b live; ↵Arthur Hanson Rasmusson7 days
| | | | committed experiment e7ff3bf7)
* STATE-CURRENT: 10:12 check-back snapshot (hold-all-unreadable experiment ↵Arthur Hanson Rasmusson7 days
| | | | committed, module e7ff3bf7, campaign 239-262 validating)
* STATE-CURRENT: 06:50 check-back snapshot + debugging-options catalogueArthur Hanson Rasmusson7 days
| | | | Refresh the status page: the acceptance is holding under hardening (per-op once bitmap, epoch/content-hash gate, 15 s CE grace; first-attempt 86% -> ~94-95%, fakes/run 3.39 -> 0.61), the hold-all-unreadable experiment is live, and the residual classes are named (late-decode corruption, early UVM channel-manager stall, guest init panic). Add an options section listing candidate techniques that would accelerate debugging toward end-to-end CUDA (deterministic fault injection, offline pump model, structured host tracing, guest-memory forensics, GR-wall metadata/golden reference/static-analysis throughput, cheaper supervised cycles, concurrency checks, tooling automation) - explicitly not directives, each requiring an eng-ops admission record.
* vgsp: hold every unreadable CE entry for the grace; delete the silent ↵Arthur Hanson Rasmusson7 days
| | | | | | | | | | pre-rescue fake An unreadable CE entry whose channel already had a decoded release VA was faked immediately and consumed with no log line, before any rescue attempt. A later pin-batch rewind then executed the skipped copy against a staging buffer the client had since refilled - the deterministic vadd input shift seen in runs 94/122/151/173b/215b, each with a silent pre-rescue fake. Now every unreadable CE entry with an expected payload is held for the bounded grace and the rescue is retried on each pass, so a translation that is still coming wins and the work runs before the release. Only an entry whose release was already delivered (the channel moved past entry_want) is consumed at once; the post-rescue fake remains the bounded, visible escape. The CE grace default moves 15000 -> 25000 ms (a translation arrived ~17 s after first examination in 215b). Under live campaign 229-236 (module 97eba5b7; green so far).
* docs: record GR promote-wall static findings (handler/commit map, ↵Arthur Hanson Rasmusson7 days
| | | | external-VAS vaList gate, rec-677)
* vgsp: widen the CE pending-entry grace to 15 sArthur Hanson Rasmusson7 days
| | | | | | | | | | | A consumed entry's work is never run; if its release lands via the fallback before the entry's copies have executed, the client refills the staging slot the copies then read (observed as the deterministic one-chunk vadd input shift). Keep untranslatable CE entries pending longer so their copies run before any release reaches the client. 8-cycle pilot (141-148): zero corruption; a red-fingerprint cycle (held=1165, ring_auto=6) healed to ring_auto=26 with faked=0 and the exact checksum, where the 8 s window recorded 1 corruption in 36.
* vgsp: never run work for a slot consumed without it (epoch mark + ↵Arthur Hanson Rasmusson7 days
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 Rasmusson7 days
| | | | | | 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 Rasmusson7 days
| | | | | | | | | | | | | | | | | | | | | | | | | 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.
* greeneye: GMMU/FBIF observability, PTE decoder and oracle, MPU/libos ↵Arthur Hanson Rasmusson7 days
| | | | | | simulator wave Simulator development wave (docs 42-44): GMMU page-table entry decode with its oracle/workflow harness, FBIF observability, and MPU/LIBOS device surfaces in the device model, plus refreshed boot/machine/profile data (tu104-570.144), the qemu-line results, and the new unit tests. Docs 00/06/35-41 updated to match; harness helpers and .gitignore included.
* vgsp: per-op once-only execution bitmap for retried GPFIFO entriesArthur Hanson Rasmusson7 days
| | | | | | The entry-identity gate suppresses every operation on a replayed entry, but an entry held because one operand's targeted scan was still running is decoded again on retry, and the ops that already succeeded would re-run against a staging buffer the client has since refilled (observed: a retried HtoD wrote the second vadd input half into the first). Track a per-slot bitmap of the operations (0..63) already executed for the slot's current entry identity, plus a complete flag for the pass that finished with no operand pending. On replay, a complete entry suppresses all ops; otherwise the bitmap decides per operation. Successful fills/copies set their bit, and the skipped count is published as ops_once in the drain line.
* STATE-CURRENT: 18:45 check-back snapshot (first green end-to-end guest CUDA ↵Arthur Hanson Rasmusson7 days
| | | | | | acceptance; 14/15 repeat cycles green) Refresh the public status page for the 2026-10-04 acceptance: noclaim38/39/40 report MAIL + VADD n=1048576 bad=0 checksum=392344090.500000 + STATUS OK with identical hashes (committed aa3520f2); the repeat campaign shows 14 of 15 green with the remaining failure the known intermittent guest-side flake. Update the milestone ladder (CUDA kernel execution now green via the no-claim host bridge; guest engine forwarding to the physical GPU still the open backend wall) and the milestone index/log.
* vgsp: end-to-end CUDA acceptance in the guestArthur Hanson Rasmusson7 days
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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).
* STATE-CURRENT: 15:12 check-back snapshot (no-claim bridge reaches guest ↵Arthur Hanson Rasmusson7 days
| | | | vectorAdd launch; mail read-back fixed; bridge slot oops + approved reboot; post-reboot run blocked by guest boot panic)
* STATE-CURRENT: 21:12 check-back snapshot (2026-10-03 victory wave, no-claim ↵Arthur Hanson Rasmusson8 days
| | | | Xid recovery, GPU-only VA->PA wall)
* vgsp: host CUDA bridge + sema release recovery; greeneye simulator waveArthur Hanson Rasmusson9 days
| | | | | | | | - 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
* STATE-CURRENT: 22:12 check-back snapshot (first real guest victory program ↵Arthur Hanson Rasmusson9 days
| | | | exercised against the physical backend; reaches device properties then stalls in UVM channel path)
* STATE-CURRENT: hourly check-back snapshot (2026-10-02 18:12:01)Arthur Hanson Rasmusson9 days
|
* STATE-CURRENT: 17:12 check-back snapshot (GR promote wall = externally-owned ↵Arthur Hanson Rasmusson9 days
| | | | VAS; shared-VAS opens 0xc5c0 object-alloc wedge; host in locked fail-safe pending reboot approval)
* STATE-CURRENT: 16:12 check-back snapshot (GR modes 18/19; mode-19 wedge ↵Arthur Hanson Rasmusson9 days
| | | | cleared by approved reboot; commit/RAMFC wall unchanged)
* kernel: capture the guest's PROMOTE_CTX entries; add promote mode 19 ↵Arthur Hanson Rasmusson9 days
| | | | | | | | | | | | | | | (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
generated by cgit v1.2.3 (git 2.39.1) at 2026-10-12 06:50:03 +0000