open-iov.git/kernel/gsp_phys_booter.c, branch stallfree

vgsp: fail4 r229 - REC-DUMP per-rec VA->HPA->reloc census at submit

2026-10-18T19:12:26+00:00

The r229 ctaid_probe came back as: PROBE1 (coordinate map) perfect, PROBE2 (flat A read) wrong at every element - band 0 read A's own values at wildly wrong offsets (16382/16383 = A's last elements), bands >= 1 read float-typed data. Writes are flawless; the engine's READ of a freshly H2D'd 64 KB buffer returned foreign content, so before anything else the next capture needs the exact (va, hpa, reloc_va) triples the engine will read for that launch. REC-DUMP logs the submit's rec table at launch build time: all recs for small launches (n_data <= 64, the probe class), first/last 8 for larger ones, gated by gsp_phys_gr_copyout_dump. Comparing the A buffer's recs against the H2D landing (and against each other: distinct VAs collapsing onto one HPA, or HPAs outside the uploaded range) names the wrong-read source directly. Logging-only; greens safe. (cherry picked from commit f83ef995c17fba896950cc7f1818c65ac8839ac4)

vgsp: fail4 r227 - INPUT-ALIAS-WIT rec census + RETIRE-WIT rec-array witness

2026-10-18T18:53:45+00:00

r227 verdict inputs: GRID-WIT == the guest's own geometry for every kernel (gemm_nn w12=0x10 w13=0x4, gemm_nt w12=0x4, softmax w12=0x40, block dims in w18/w19) - no QMD geometry emission bug; the old consecutive-pair IN-ALIAS stayed silent. Two new witnesses for the next capture: - INPUT-ALIAS-WIT: per-launch census of the copy-in recs (the exact VA -> HPA -> content triples the engine reads, inputs included; the fill already covers them as recs). Every non-zero rec is compared against the last 64: distinct VA -> same HPA is the resolver-aliasing smoking gun; distinct HPA with equal content is the upstream-write-clone class. Zero pages excluded on both sides. Replaces the consecutive-only check. - RETIRE-WIT: one line per launch at the retirement wait with n_data, n_tracked and the first/last recs' va/reloc_va/bi. r227's numbers are impossible under this source (retire n_tracked 4/4/4/1/1/16/16 vs copy-in/copy-out 1482/1418/1354/913/864/882/1290 recs for the same launch), so either the rec array genuinely aliases reloc VAs at run time or the deployed module differs from this tree; RETIRE-WIT shows which in one line (sequential in-region rels + n_data=1482 with n_tracked=4 would prove the former). Logging-only; no behaviour change; greens safe. Build green. (cherry picked from commit 1dbde7967bda4ba51dadf8a96e8aeaacc44c5575)

vgsp: fail4 r226 - zero-filter alias witnesses + GRID-WIT QMD geometry dump

2026-10-18T17:28:40+00:00

r226a: the green victory_mail run produced 10 IN-ALIAS-WIT lines that are all false positives - consecutive all-zero pages from fresh cudaMalloc runs (csum=0x00000000), not aliasing evidence. Filter all-zero pages out of both alias comparisons: a page counts as zero only when the csum is zero AND every word is zero (csum alone can hide cancelling contents); zero pages are neither candidates nor partners. Also: the r224 band corruption (rows >= 16 of every launch replicate one tile) starts at a CTA-band boundary while the QMD is passed through verbatim - but the current dumps never show the geometry words the engine actually fetches. GRID-WIT logs, once per launch, the geometry-relevant QMD words of the deposit the engine will run: w12/w13 = CTA raster width/height/depth (gridDim), w18/w19 = CTA thread dimensions (blockDim), w18.lo = QMD version nibbles, plus w4/w5/w8/w17 (PCAS/cache-control, prefetch low word, shared-memory size). With the guest-side GEO line added to transformer_mt.cu (8 lines per run, one per chain) the next capture can prove or refute an emission mismatch in one comparison. And IN-ALIAS-WIT now prints both HPAs with a classification token: equal hpa = the resolver served one page for several VAs; distinct hpa with equal contents = the guest pages genuinely hold the same bytes (upstream write aliasing). Logging-only; no behaviour change, safe for the green clients. (cherry picked from commit dc1e693d598d3a32d1e6a87b94ff91dcbc99101c)

vgsp: fail4 r224 alias witnesses - OUT-ALIAS-WIT / IN-ALIAS-WIT + pre/post csum

2026-10-18T16:39:31+00:00

r224 evidence: the failing outputs ARE produced by the engine and read back byte-identical (OUT-PAGE-WIT vs sema-bigcopy src16 match exactly), but the engine's result is structurally corrupted: for every gemm of the tested chains the row band >= 16 (the by>=1 CTA band) replicates a single tile per output buffer (Q band=[0,-7.96875], K band=[7.96875,7.96875], ...) while the first pages carry the correct/partial values; the corruption starts exactly at the row-16 boundary. The pre/post csum pair proves each 'changed' page was really rewritten by the engine (bounce != copy-in baseline), so the replicated band is engine-authored, not pass-through. Add the two witnesses that name the replication source in the next cycle: - OUT-ALIAS-WIT: each changed page's first 8 bytes matched against the earlier changed pages of the same launch -> logs (va, bi) partner pairs. - IN-ALIAS-WIT: consecutive copy-in recs with identical content (equal per-page csum) -> a replicated INPUT region (one page served for many VAs, e.g. an X/weight buffer) is caught before any launch runs. - OUT-PAGE-WIT extended with pre/post csum. All bounded, behind the existing gsp_phys_gr_copyout_dump gate, and using the established single-inflight static scratch discipline. (cherry picked from commit 7c9d48847cffa2a21263515b94bdb57ad2a9357c)

vgsp: fail4 discrimination tooling - copy-out page witnesses + full-boot bigcopy resolution budget

2026-10-18T16:10:03+00:00

Four guest CUDA clients fail all-bad while four pass; the aggregate counters cannot separate 'engine result never produced' from 'produced but written to a different guest page than the client's read resolves'. Add the two per-page witnesses that correlate the write side with the read side: - gsp_phys_gr_copyout_dump (booter, default 1): per-changed-page OUT-PAGE-WIT va= hpa= first8/last8=, bounded 12 pages per launch, plus one RELOC-CENSUS line per launch (gaps vs late-resolved words vs late pages). - sema_bigcopy_log (sema service, default 24, was a hardcoded per-boot budget): the svc_copy large-copy proof already logs both operands' resolved VA -> pa/aperture/provenance and the first 16 bytes each side; raising the budget past the boot's head makes the failing clients' H2D/D2H resolutions visible. Discrimination test for the next cycle: same device VA on OUT-PAGE-WIT (copy-out HPA) and sema-bigcopy (D2H source pa) with different PAs proves the produced-but-misplaced class; equal PAs redirects to the readback content/engine-input path. (cherry picked from commit 78ea8b7807231ac418a17b85c29ed1845e1b0062)

vgsp: bounded GR launch completion (GR-STALL), r220 hold storm fix, churn caps

2026-10-18T16:10:03+00:00

Every GR launch now either completes or fails fast with a distinguishable dmesg line; no host wait in the launch/consume path can run forever. - gsp_phys_gr_wait_max_ms (new param, default 60000, clamp [10000,600000], 0 = built-in per-ladder bounds only): absolute per-launch submit budget. Checked in the GR poll loop (after the release acks) and in the retirement-retry loop; on expiry the submit fails out ('vgsp-gr: GR-STALL-wait-max ... action=fail') or the retry loop stops ('GR-STALL-retry ... action=proceed'), so the chain of individually bounded ladder phases can no longer hold the single-inflight work item (and the client's launch wait) for the ladder sum. - gsp_sema_service: pass-top svc_fwd_outcome_check() completes a forwarded GR request that no hold owns. A GR push with no push-level release records engages no release hold, so a backend failure (ladder timeout, abort) left the QMD completion word unwritten and the client waited to its own timeout (r219/r222, qmd_rel frozen at the previous value). The check authors the word in software (full resolver, forward-only, latched once) and logs 'GR-STALL-backend ... action=proceed'. It also covers a *successful* submit whose release0 could not target the guest page (engine completion landed on the module semaphore only) - the work item records gr_rel_unobserved for that. - Consume tail: a GR capture consumed without ever being forwarded (a data-stall / busy-defer / no-capture hold fell through) now authors its QMD completion release, latched per capture, and logs 'GR-STALL-hold'. - r220 hold-storm fix (196 s re-hold): the m150/m156 data-stall hold window is keyed to the GPFIFO slot index, and a pin-batch rewind replays the same launch at different slots, so the window re-armed on every pass; the absolute per-launch backstop could never fire because its record fields were excluded from the pump snapshot write-back list (the GRFIX NOTE record leak) and the fill gate defaulted off. The four bound fields are now written back and svc_gr_hold_bound_expired is effective on the default path (cap gsp_phys_gr_hold_max_ms, default 3000 ms, keyed to the launch push VA via svc_gr_launch_va so nothing re-arms it across rewinds); the busy-defer hold site consults the same bound. On expiry the entry is consumed with the software completion and logs 'GR-STALL-hold-bound'. - Hold expiry/failure edges log 'GR-STALL-fwd-hold' / 'GR-STALL-fwd-fail' with waited_ms for held forwarded launches. - Anti-degradation under pin churn/leftover clients: svc_rescue_scan_range (up to 6 GB of guest-RAM reads on the service thread) is capped at 3 s per range with RESCUE-SCAN-CAP logging; the ledger eviction burst triggers a logged wholesale cache reset (LEDGER-RESET cap-and-degrade, 256 evictions); pending-ring overflow is counted and surfaced (PENDING-OVF, pend_ovf in the drain line). New diag tokens: gr_swrel/pend_ovf, ledger resets, rescue scan_capped, work_gr stall_wait_max/stall_retry/wait_max_ms. Green behavior: normal launches complete in ~0.2-11 s and never approach the budget; the hold bound only fires where the old path could stall forever. make kernel green; only pre-existing warnings. (cherry picked from commit dc3650105f163631bb826ae3685a7d6e9025bfe8)

vgsp: m91 - first-fault capture + QMD instruction-cache invalidate for the SM I-fetch lottery

2026-10-18T16:10:03+00:00

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)

vgsp: refuse PTE-page code sources in the Tier-2 program-pair path (CODESRC-SUSPECT fallback)

2026-10-18T13:24:48+00:00

r221 evidence: six CODEHASH-suspect launches resolved six different client code VAs to the same page (deterministic guest allocation within one boot) and all carried valid kernel prologue words at the QMD entry offset; the SUSPECT tag was the zero-window false-positive mode of the CODEHASH content test, and no source page observed was PTE-shaped. The class remains real: the program pair (QMD w48/49) is copied verbatim into the page the engine I-fetches from, so a stale landing, walk or pin answering with an empty, PTE-shaped or module page-tree page would execute PTE/filler bytes as SASS. CODESRC, before the Tier-2 program-pair copy (additive, once per launch): - detect (a) empty source (entry+sampled windows zero), (b) PTE-shaped entry run (>=12/16 identically-flagged valid entries, or mostly-zero with only PTE-signed entries), (c) source HPA on one of the engine page-tree's own module chunks (main PT, guest PT pool, shadow pools, qmdwin); - on detection re-resolve through the late resolver (guest-walk order, the alternative to the fill's ledger-first order) and adopt it only if different and not itself suspicious; otherwise withdraw the page from the submission (no copy, no mapping, QMD pair kept at the guest VA - the per-pair ptr_guest behaviour). One rate-limited 'vgsp-gr: CODESRC-SUSPECT va= pa= alt= used= why=' line. Greens-safety: no observed launch (green or suspect) matches any trigger: entry words are non-zero and distinct, entry runs are not PTE-signed, and a guest HPA cannot equal a module chunk DMA; with no match the flow is byte-identical to before (same memcpy, copied++ and dump gate).

vgsp: code-fetch content verification instrumentation (CODEHASH) + static trace

2026-10-18T12:33:21+00:00

Static trace of the GR code-fetch path: the engine's instruction fetch base is the QMD word 48/49 program pair (svc_gr_qmd_decode, gsp_sema_service.c); the entry page resolves ledger-first (svc_gr_page_note) and is authored at submit as either a Tier-1 guest-VA->HPA identity PTE (gsp_phys_rmcall_gr_map_va_locked) or a win0 shadow copy of the guest page with the QMD pair rewritten to the shadow VA (gsp_phys_backend_guest_gr_submit); the guest page content was written by the emulated H2D copy path (svc_copy + svc_ledger_store landing). CODEHASH: one bounded line per launch at author time sampling the resolved code region (entry offset 16B + PA+0/mid/end windows, up to 4 consecutive tracked code pages) on the source landing page and the engine-visible shadow copy: 'vgsp-gr: CODEHASH va=0x%llx pa=0x%llx n=%u h0=0x%016llx ent=... w=... sh0=... SUSPECT|ok'. Emitted for suspicious content (all-zero windows, zero entry word pair, four identical entry words) or the first 3 healthy launches per boot; 'CODEHASH-UNREADABLE' when the entry page has no host-readable landing. Additive, no behavior change (Tier-1 and shadow call sites, once per launch).

vgsp: copy completeness hardening + COPYAUDIT/COPY-TRUNC instrumentation

2026-10-18T12:07:49+00:00

Map every guest-data copy path and its caps (CE soft copy/fill/inline, GR fill span, late/gap span, bounce copy-in/out, forwarded CE copy, launch-page pools) and close the two silent partial-data holes: - late/gap span cap (gsp_phys_booter.c): a word cut at the 16-page cap was still rewritten to the partial run; probe one page past the cut and log COPY-TRUNC when it is resolvable (r218 shape: 4 words x 16 pages = all four cut at the cap). - GR fill span walk (gsp_sema_service.c): a mid-span resolution miss after >=1 authored page now logs COPY-TRUNC (was GRFILL-DROP only, launch proceeded with fill_hold=0). Instrumentation (all additive, no new locks/waits, readback uses the same accessor the write just used): - COPYAUDIT path=... va/len/done for every >=32 KB copy (CE soft copy, fill, GRCE inline, GR bounce/gap copy-in and copy-out). - COPY-MISMATCH 16-byte start/end destination readback vs the written bytes right after the copy (CE first/last chunk; fill and inline first 16 B; GR staging first+last 16 B of every page). - COPY-TRUNC on every partial copy: CE loop returns, fill/grce chunk failures, short GR staging/copy-out counts, reloc-fix-span, gr-fill-span; want>done is rate-limited but never silent. make kernel green; only the pre-existing %x warning at gsp_phys_booter.c:14088.