summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAge
* vgsp-gr: m155 extend the re-arm with the mode-35 lane-enable tail (HF-3)HEADmasterArthur Hanson Rasmusson5 hours
| | | | | | | | | | | | | | r154: after the second client's idle period the FECS saved/unloaded the context (SKED rec: cwd0=0x12486 fecs_cur=b0633ee3 -> cwd0=0x2086 fecs_cur=0 and no change ever after) and every later forwarded launch acked (qmd_rel/ch_rel) while dispatching nothing - including all three outcome retries with fresh ring entries (0/205 changed, 720 ms no-writes, x4). Re-issuing only GPFIFO_SCHEDULE+TSG_GPFIFO_SCHEDULE+doorbell did not revive dispatch. The extended re-arm now replays the mode-35 lane-enable tail first (GR_SET_CTXSW_PREEMPTION_MODE CILP + SET_TIMESLICE + DEVICE_SCHED - the proven-accepted stage-4 sequence, HF-3 design), then the schedules and the doorbell. Poison variants (explicit PREEMPT/tail, BIND, PROMOTE) remain excluded.
* vgsp-sema: m154 drop injected pins that collide with a live channel ringArthur Hanson Rasmusson6 hours
| | | | | | | | | | | | | | | r153 root cause (3rd-client userspace spin for the rest of the boot): the guest scanner's merged CE-window run (va=0x121000000 len=0x40000; the merged length varies per session) covered a CE channel's GPFIFO ring VA 0x121010000. svc_ipin_store took precedence in the ring read path, so the ring read the guest page at the wrong PA (0x102e02000): an all-zero entry was silently consumed, the pool release was never authored (pushes frozen at 1643, crel frozen), and victory_matmul spun in userspace for 50+ min. The ring VA translation must come from the channel's own discovery path; an injected pin inside any live channel's ring range is always wrong - drop it (counted + logged, first 8 per session). Validated on the next cycle: 'injected pin ... DROPPED' lines plus 'entry[1] raw!=0', advancing pushes, MATMUL bad=0 STATUS OK.
* vgsp-gr: m153 retry only on zero writes (drop wrong-place heuristic)Arthur Hanson Rasmusson7 hours
| | | | | | | | | | | Live r153 evidence: the highest-reloc data entry (bi=204) is a UVM-internal buffer that correct launches never write, so the 'top operand untouched' condition fired on correct executions and re-executed them up to 3x - a correctness hazard for side-effecting kernels (atomics/printf) and pure waste otherwise. The honest execution witness is the retirement wait's changed count; only zero-writes retries now (safe by construction: a kernel that wrote nothing has nothing to duplicate). Read-only kernels pay the bounded extra polls.
* vgsp-gr: m152 fix - extension scratch pool as 48 single-page chunksArthur Hanson Rasmusson8 hours
| | | | | | | | | The server refuses multi-page client memdescs for these buffers (a 48-page chunk aborted stage 2 with rpc_result 0x1f + firmware ASSERT 0x5ab0214 at ALLOC_MEMORY buffer 30); the only accepted shape is the existing single-page-per-PD0-slot pattern. GUEST_PT_EXT0..47 are 48 separate single-page chunks; BUF_COUNT 33 -> 81 (handle range still inside the meta assert bound).
* vgsp-gr: m152 scratch-PT alias cache + extended pool; m153 outcome-verifying ↵Arthur Hanson Rasmusson8 hours
| | | | | | | | | | | | | | | | | | | | | | | | | launch retry m152: the Tier-2 shadow alias pool consumed one never-reused 128 B fetch line per mapping per launch (512 lines/boot), so a normal launch mix exhausted it permanently: every later launch that needed a new mapping was refused (the deterministic r152 'launch refused: no Tier-1 mapping' loop). Two fixes: (a) an HPA-keyed alias cache in map_shadow_locked that returns the existing never-rewritten VA for a page already mapped, so repeat launches of the same buffers/sem pages consume nothing; a hit reports line_out = ~0 so contiguity bookkeeping never extends an old line; (b) a 48-window extension pool at VA 0x04000000 (PD0 indices 32..79, one 48-page PT chunk) raising capacity to 2048 lines/boot. m153: the intermittent per-boot mis-execution classes (engine wrote nothing; or wrote into a lower operand window while the output operand stayed untouched - both complete with qmd_rel/ch_rel satisfied, live evidence in r152 smiley: passes wrote b into the a window / nothing / correct-after-10s-retry) are now detected by the m151 retirement wait and retried: refill the bounce window from the guest inputs, re-publish the same method block on a fresh ring entry, re-issue schedule, re-poll, re-wait - bounded by the timeout path's attempt budget. Gate param gsp_phys_rmcall_gr_nowrite_retry (default 1).
* vgsp-gr: retirement wait - whole-window footprint with adaptive exitsArthur Hanson Rasmusson16 hours
| | | | | | | | | | | | | | Footprint-by-inference (max-reloc contiguous run, launch-page exclusion) failed twice: the fill's candidate list ends with the launch's own bank/ param pages, so the inferred output run was 3-4 pages (r150/r151: '0/3 pages changed after 72 ms (no writes)') and the wait exited before any real output landed. Replace with a whole-window count over every resolved data page plus cheap adaptive exits: - all pages changed -> done (one poll in the normal case), - partial count stable for 3 polls -> stores settled, - no change for 600 ms -> no output for this launch, - hard cap 1.5 s. No inference, no exclusion list, bounded cost.
* vgsp-gr: retirement wait - exclude every forwarded page from the footprintArthur Hanson Rasmusson16 hours
| | | | | | | | | | | r150's first cut excluded only QMD-word pages; the fill also relocates the 0xffffffff (non-QMD) forwarded pages (pushbuffer/indirect/bank pages) as high-VA candidates, so out_base landed on the bank-page group, out_pages came out 3 and the wait exited after 72 ms - losing the late-write capture it exists for (smiley r150: '0/3 pages changed after 72 ms (no writes)' followed by mixed 8-changed/0-changed/32-changed copy-outs and one wrong pass). Now every forwarded page VA is excluded, so the footprint is the real output operand (32 pages for smiley, 64 for matmul).
* guest-diag: demand pinning for stalled CE VAs (event-independent hole filler)Arthur Hanson Rasmusson16 hours
| | | | | | | | | | | | | | | | | | | | | | | | | | The one-shot #sem kprobe event that drives the CE push-buffer chain resolution can be lost (trace rotation, scanner restart, slab kptr reuse), and the chain resolver then never learns a client - every GPFIFO entry of its CE channels is grace-skipped and the client spins on its tracker semaphore (the copy-heavy stall class: streams2/memcpy/multikernel/saxpy in r148; smiley as a later client in r147 took ~90 s to recover). New demand channel, both ends here: - pin_gr_stream: _demand_loop scans the host dmesg for 'stalled VA #N: 0x...' (the service logs each distinct unreadable push VA once), tracks each sighting, and re-sends every 20 s for up to 5 min to /tmp/guest_want_vas.txt in the guest (via the guest agent). - guest_pin_stream: the main loop reads new VAs from that file and resolves each by CONTENT against the nv_vm_map_pages vmap areas (resolve_va_by_content: candidate leaf page at the VA's in-window offset, +1/-1 neighbours for the header-page offset ambiguity, host-plausible method-stream prefix). On a match the exact pair is emitted; only the requested VA is pinned, so a wrong candidate cannot poison other VAs. Also fix the scanner start: the kill-first pattern must be anchored (^python3 /tmp/guest_pin_...) - the unanchored pattern matched the deploy shell's own cmdline and every start attempt killed its own shell before launching the scanner (r149: no scanner for the whole boot).
* guest-diag: single-instance scanner start + full-re-assert backoffArthur Hanson Rasmusson17 hours
| | | | | | | | | | | | | | | | | r148 ran THREE guest scanners (pin_gr_stream install_and_start retried while a partially-failed first attempt had already started one, and the pid-file kill missed it). Each scanner re-asserted the whole CE pair set every 2 s; with a fully fragmented pair set (descending PAs, one page per line) that is ~2 k debugfs writes/s per scanner, and the guest hit load 19 with clients wedged spinning in userspace. - pin_gr_stream._start_cmd: kill EVERY existing scanner first (pattern assembled at runtime with printf so the command's own cmdline cannot self-match), then start exactly one. - guest_pin_stream._emit_ce_mem_delta: the full re-assert keeps its 1.5 s cadence for the first STREAM_FULLREM_FAST_S seconds of a mem's life (the client-switch flush race), then backs off to STREAM_FULLREM_SLOW_S (10 s) as a safety net. Configurable via env.
* vgsp-gr: retirement wait - correct footprint (exclude launch pages) + ↵Arthur Hanson Rasmusson17 hours
| | | | | | | | | | | | | | | | | | | | adaptive exits - Footprint: exclude data entries whose guest VA is a forwarded launch page (qmd_word pages) before picking out_base/out_pages. The fill relocates the launch's own param/bank pages as high-VA candidates, which made out_pages the whole 205-page budget and forced the full 1.5 s wait on every launch (r147: '64/205 pages changed ... (TIMEOUT)' on green matmul). - Adaptive exits: no writes at all after 60 ms (identical-rewrite benchmark launches / no-output footprints) or a partial count settled for 3 polls (masked kernels) end the wait early; genuinely late writes are still caught. Log now carries the reason suffix (no suffix = full footprint). Live evidence from r147 with the first cut: the exact failing order mail->matmul->smiley ran green->green->green (smiley recovered to 32/205 changed, C window written; earlier boots showed 0-8 changed and STATUS FAIL). victory_math/vector_add still fail on the >256 KB per-operand window cap (chunked data path is the next wall, not this class).
* vgsp-gr: output-footprint retirement wait + two-bank win0 rotation + page hashesArthur Hanson Rasmusson18 hours
| | | | | | | | | | | | | | | | | | | | | | | | | | | Two independent hardening changes for the per-boot 'all-wrong' class: 1. Output-footprint retirement wait (gsp_phys_gr_output_retire_wait): qmd_rel is a schedule/fetch ack, not a data-path retirement - the engine's stores into the bounce pages can land after it. Copy-out (and the next launch's copy-in) before those stores land loses them: the guest observes zeros for a completed launch (matmul csum=0, r146) or stale/mixed content (smiley b-into-a, r143/r145). The wait polls up to 300x5 ms, success path only, until every page of the output footprint (contiguous descending reloc run from the max reloc_va) differs from its copy-in checksum; logs 'output retirement wait: N/N pages changed after T ms'. 2. Two-bank win0 rotation: pool grows 8 -> 16 slots (VAs 0x1e0000..0x1effff, below the mail-injection slot 0x1f0000), bank selected by submission epoch (epoch & 1). A launch's copy into one bank can no longer clobber the pages the previous launch's engine index/data fetches may still read. 3. Evidence: full win0 param page dump rows + FNV-1a pre/post hashes of the win0 param page and the guest param page, so a torn/mixed read source is provable from the log on the next occurrence. static_asserts: pool < mail slot and SLOTS == 2 x BANK. Build clean. Live validation pending (next cycle: mail->matmul->smiley->victory_math-> vector_add).
* guest-diag: heal session-flush pin wipes with periodic full CE re-assertArthur Hanson Rasmusson18 hours
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The host wipes its whole sema map when the previous client's last channel closes ('session flush (all channels closed)'). A pin batch that raced in for the new client (observed: the 1-page 0x120000000 pin emitted in the same second as the flush) was lost, and the scanner's content-gated delta never re-emitted the unchanged pairs - so the second client's CE pushes were permanently unreadable (sema-probe 'NO ENTRY for page 0x120000000'), every GPFIFO entry was grace-skipped (r144/r145 matmul and mail stalls), and the guest spun in uvm_tracker_wait_for_entry. Fix (scanner, guest side): - _ce_mem_pages: walk the whole vmalloc area (minus header off), not the size-derived prefix that stopped one page short of the write frontier. - _emit_ce_mem_delta: full re-assert mode every KC_FULLREM_S (1.5 s) plus every fresh_map pass; emits every translatable pair content-independent, merged into contiguous runs. Zero-content pages are pinned on purpose: the pin carries the translation, the host reads live content. - missing pages retried with the negative PA cache popped (bounded 512/pass). Fix (host tool): - pin_gr_stream._flush: never dedupe single-page repeats of the CE window (0x120000000..0x121000000) so the re-asserts land. Live-validated in r145 (same-boot, no rebuild): mail green as 4th client, matmul green as 2nd client (bad=0, 64-changed acceptance of 857fe5f9), both with zero 'stalled VA'/'skipping stale entry' lines; pre-fix the same sequences stalled. Headless smiley all-wrong (bad=131072) reproduced independently and is the next target (engine-side constant class).
* vgsp-gr: move win0 shadow pool clear of the data bounce window (matmul C ↵Arthur Hanson Rasmusson26 hours
| | | | | | | | | | | | | | | | | | | | | | | | | rows 0..31) m150 grew the GR data bounce window to 208 pages at main-PT slots 0x110..0x1df but left the win0 QMD shadow pool at VA 0x190000 (slots 0x190..0x197) - inside the new window. The win0 plant is unconditional on every gsp_phys_rmcall_pdb_build() and runs after the one-shot bounce plant, so it hijacked the PTEs for bounce pages 128..135, which hold the first 8 pages of the third operand. victory_matmul's C rows 0..31 (8 pages x 256 floats = 8192 elements) were written into the shadow pages and lost: MATMUL bad=8192, copy-out '56 changed by engine (first bi 136)'. Move GSP_PHYS_RMCALL_VA_GR_SHADOW0_BASE to 0x1e0000 (slots 0x1e0..0x1e7), directly above the last bounce/mail/marker page (0x1df000) and below the 0x200000 guest scratch window; both the plant and the launch-time shadow VA derive from the macro. Add a static_assert so any future bounce growth cannot silently re-introduce the overlap, and correct the stale slot-range comments/logs (0x108..0x10f -> the current range). Evidence: /tmp/opencode/dmesg-r143-mailmatmul.log (main PT[190..197] = win0 chunk DMAs; 'window[160] reloc=0x1b0000 changed=1', 'window[128] reloc=0x190000 changed=0'; MATMUL bad=8192). Live validation pending: a fresh cycle's victory_matmul must print bad=0 STATUS OK.
* gitignore: never track backup/editor leftovers (star.bak patterns)Arthur Hanson Rasmusson27 hours
|
* vgsp-sema: budget the data window - only real device operands get the full spanArthur Hanson Rasmusson28 hours
| | | | | | | | | r141 showed the 68-pages-per-pointer change starved the operands: the launch's own QMD VA (0x204608000) and other low-VA candidates each consumed 68 window pages, so a 256 KB operand resolved 0 pages before the 205-page cap. Give the full span only to high, cudaMalloc-shaped VAs, skip the QMD VA entirely, and give every other candidate one page. Three 256 KB operands (3x68=204) now fit.
* STATE-CURRENT: 2026-10-14 status refresh (physical guest compute, ring fix, ↵Arthur Hanson Rasmusson28 hours
| | | | scrubber fix)
* vgsp-gr: enlarge the data bounce window to 208 pages (256 KB operands)Arthur Hanson Rasmusson28 hours
| | | | | | | | | | | | | victory_matmul (256x256 float: 256 KB per operand) failed with all-wrong results while 128 KB workloads passed: the relocation bounce window was 112 pages with a 100-page data cap and 33 pages per pointer, so each 64-page operand was truncated and the engine ran on partial/mismatched windows. Grow the planted bounce window to 208 pages (main-PT slots 0x110..0x1df), move the mail page to the last data-free slot (206, marker 207), and raise the per-pointer cap to 68 pages and the data cap to 205 (three 256 KB operands = 3x68 = 204 <= 205). Operands larger than 256 KB still hit the cap and need a chunked data path (documented at the define).
* vgsp-gr: bounded fresh-entry retry for a forwarded launch whose QMD did not runArthur Hanson Rasmusson28 hours
| | | | | | | | | | | | | | | | | A green forwarded launch completes in ~170-195 ms, but an intermittent subset times out with qmd_rel stuck at 5 (cold context save/unload, or an entry the PBDMA never fetched). The existing recovery only replays the schedule verbs, which cannot help once the entry was fetched or never latched, so the client fell back to the software release and read stale/zero results. On a timeout, after the schedule re-arm, re-publish a FRESH ring entry with the same PB/QMD content and re-issue schedule+doorbell, up to GSP_PHYS_RMCALL_GR_ATTEMPTS (3) with a GSP_PHYS_RMCALL_GR_RETRY_MS (2000 ms) poll. Safe against double execution: the timeout path never copies the result out to the guest, so a timed-out attempt did not reach the client - only the eventually-successful attempt is visible. New counter gsp_phys_gr_retries and a 'retry N/M fresh ring entry' log line.
* vgsp: user-lane GPFIFO depth must match the host ring modulus (8)Arthur Hanson Rasmusson29 hours
| | | | | | | | | | | | | | | | | | The host publishes every forwarded launch into the one-page ladder ring modulo GSP_PHYS_RMCALL_GPFIFO_ENTRIES (8). Commit 3b82047c declared the mode-35 user-lane channel with 1024 entries for capture fidelity; the engine's GET/PUT then wrap at 1024 while the host wraps at 8, so at the host's first wrap (GP_PUT 7 -> 0) the engine desyncs and never fetches another entry: launches 1..7 green, the 8th and all later ones silent (qmd_rel=5, ch_rel=0), which is the 'launch lottery'. Live proof (r138): the failure fires exactly at slot=7 (first wrap) and every launch after it fails; vecadd_loop (100 launches) dies at the wrap. M1's two-launch acceptance never wrapped, so the regression was latent. Set the declared count back to the host ring constant; the wrap-only fidelity difference against the captured real-client ring is documented at the define.
* guest-diag: resolve and stream the PMA scrubber buffer words (third-client ↵Arthur Hanson Rasmusson30 hours
| | | | | | | | | | | | | scrub freeze) guest_pin_stream: find the scrubber channel buffer among the nvidia vmap areas (size in the CeUtils channel set, 906F ring shape at +0x64000 when non-empty), walk its pages with kcore and emit '#scrub <fin_pa>,<hsem_pa>' (the finish payload at +0x6c004 and the host semaphore at +0x6c000). pin_gr_stream: handle '#scrub' lines and register the PAs through the sema_scrubbuf_add module parameter, so the kernel's svc_scrub_pass can author the guest's scrub progress.
* vgsp-sema: author the PMA scrubber channel's progress (third-client scrub ↵Arthur Hanson Rasmusson30 hours
| | | | | | | | | | | | | | | | | | | | | | | | | | freeze) The guest PMA scrubber (in-guest CeUtils CE channel, 4096 GPFIFO entries) waits on its channel buffer's finish payload (offset 0x6c004) after the third CUDA session's pages must be scrubbed; nothing in the emulation authored it, so cudaMalloc froze in scrubCheckAndWaitForSize. - channel_add: detect the 4096-entry scrubber channel and stash its USERD PA/ring geometry (the channel itself is left untouched: no rank change, no pump change - the colliding numeric-handle FREE may still unregister it, the geometry survives). - sema_scrubbuf_add debug param: register the finish/host-semaphore word PAs the guest scanner resolves (vmallocinfo + kcore walk), because the RM kernel VA space collides numerically with the client CE window in the global VA map and cannot be resolved through it. - svc_scrub_pass (service thread, per pass): from the channel's own USERD GPPut, track submitted scrub blocks across wraps, then author USERD GP_GET = put, host semaphore = put and finish payload = submitted. Forward-only, idempotent, zero writes while the scrubber idles. Live-validated mechanism (r137 VM): authoring the finish word at the kcore- resolved PA let the frozen victory_matmul leave scrubCheckAndWaitForSize and proceed to its launch.
* guest-diag: content-validated delta emission for the CE push-buffer memArthur Hanson Rasmusson3 days
| | | | | | | | The one-shot CE mem emission pinned the whole 16 MB window including pages whose content was zero at the time; the host then read zeros for the other CE ranks' pushes. Sweep the mem every 2 s, skip zero pages, emit only new/changed {va,pa} pairs, and burst the Kcore PA cache every 30 s so a remap is re-emitted instead of shadowed by the cache.
* guest-diag: channel-anchored CE pool resolution for the spinning ↵Arthur Hanson Rasmusson3 days
| | | | | | | | | | | | | | | | tracking-sem case The second-client stall leaves exactly one live uvmt event: a tracking semaphore spinning with val=0 (the other channel/one-shot probes are inlined in this driver build and never fire). The sem is a member of a uvm_channel_t whose records sit in the sem's own window and carry the CE ring GPU VA (0x121010000+) plus back-to-back object handles; the channel's pool pointer is the first field at channel+0 (channel = sem-0x80), and the pool chain already satisfies _chain_mems_at once it is tried. The resolver now expands the candidate set from every ring-VA word's surrounding records and their targets before scoring. Verified live: the r134 spinning sem resolves to the CE push-buffer rm_mem with 413 pin runs, where the bare sem-window scan had produced none.
* guest-diag: keep CE push-buffer latches on stale refresh; never fail ↵Arthur Hanson Rasmusson3 days
| | | | | | | | | | | | | | freshness on an unknown page PA Two scanner defects seen in r131: (1) a resolved CE mem whose first vmap page could not be translated at store time stored page_pa=0, and the freshness check then failed on every probe, dropping the latch and re-resolving in a tight loop - and each failed re-resolution left the host with no pins for the channel at all; (2) the stale path discarded the latch before knowing the re-resolution would produce anything. Unknown PA now counts as fresh (the {cpu,gpu} object check is the evidence), and a stale refresh keeps the previous latch unless a new resolution actually emits runs.
* vgsp-sema: reject all-FF continuation chunks in the CE push read; try the ↵Arthur Hanson Rasmusson3 days
| | | | | | | | | | | | displaced pin pair The r129 cross-page evidence: a 216-byte CE push whose SET_SEMAPHORE_A + LAUNCH_DMA tail fell in the next 4 KB page, whose injected pin resolved to an all-0xFF page while the first page decoded perfectly. A continuation chunk read from an unvalidated source (injected pin, its displaced pair, or the linear window guess) is now rejected when the whole chunk is 0xFF, the displaced ipin-alt pair is tried as a new source, and a bounded line names the rejected (va, pa, src) at the fix site.
* vgsp-sema: bounded sema-norel diagnostic for readable CE pushes without a ↵Arthur Hanson Rasmusson3 days
| | | | | | | | | | | | | release The entries the pump holds for the 8 s CE grace are exactly the ones whose decode found no release. Under SEMA_DBG this logs the decode state (have_sem, rel va/payload, ops) and the first 64 push bytes for every content-bearing CE push that decoded no release (2048-line budget, all-zero reads are filtered so they cannot wash it out). Used in r129 to show that a push whose tail crosses the CE page boundary reads 0xFF garbage for its second page - the sem+LAUNCH_DMA live exactly in that tail, so only boundary-crossing pushes were undecodable.
* guest-diag: read the trace snapshot non-blocking (no stuck tail processes)Arthur Hanson Rasmusson3 days
|
* guest-diag: seed channel-event sets from the trace ring on client switchArthur Hanson Rasmusson3 days
| | | | | | | | | | clear_trace() on a pid switch dropped exactly the one-shot uvmt/uvch events of the new client when they landed in the switch instant; the pipe reader then never saw them and the whole session ran with an empty sem set (r126: vecadd_loop sem=0 for minutes while its CE entries paid the 8 s grace). Scan the ring tail once per switch and seed the sets instead - stale kptrs that are also re-learned resolve to no content and are deferred by the candidate scoring.
* guest-diag: content-score CE mem candidates and refresh stale pin setsArthur Hanson Rasmusson3 days
| | | | | | | | | | | | | | The kptr-keyed one-shot latches assumed object identity, but UVM frees and re-creates CE push-buffer rm_mems and channels mid-session and the slab reuses the same addresses; a resolution taken before such a move pinned pages that read all-zero when the host used them, so every CE ring entry stalled in the 8 s grace (r125: the live pushes sat at new vmap pages of the same rm_mem kptr). Candidates are now scored by their window content (a live push buffer is full of method streams, a freed range reads zeros) and the best is pinned - all-zero candidate sets emit nothing instead of poisoning the host map. A resolved mem is re-validated every ~2 s against its own {cpu,gpu} fields and first-page PA; when they move, the latches drop and the current truth is re-emitted.
* vgsp-sema: persist the GR data-arg hold window across pump passesArthur Hanson Rasmusson3 days
| | | | | | | | | The pump works on a snapshot copy of the channel table; without the end-of-pass write-back the hold window was re-armed every pass and a launch whose argument pointers never translate was never consumed (r122: smiley's launch held forever). Persist gr_hold_until/gr_hold_idx so the hold is exactly one bounded window per entry, then the entry is consumed as before.
* vgsp-sema: hold GR launches whose device argument pointers do not translate; ↵Arthur Hanson Rasmusson3 days
| | | | | | | | | | | | | | | | | | | | | | | | | | | | derive the CE vmap pairing per allocation Two second-client zeros/stall countermeasures: - svc_gr_data_fill now reports when a launch carries high (device-space) argument pointers and none of them resolves through any trusted source. svc_gr_request refuses to forward such a launch and leaves the capture unconsumed; the pump holds the ring entry for one bounded window per entry (gsp_sema_gr_grace_ms) and retries it, so a translation that appears a pass later (scanner pin, published directory, learned pair) is used instead of executing the kernel against unresolved pointers. On window expiry the entry is consumed exactly as before (bounded zeros, never a hang). Bounded per-session fill diagnostics name the source that serves each candidate (ipin/pin/lat/map/vas/disc/win) and dump the published vaspace walk results for misses. - The CE push-buffer kcore chain resolver derives its vmap page offset per allocation instead of using a fixed shift: the rm_mem size is read from its real offset (570.144 layout) and paired with the vmallocinfo area page count, so a leading header page is only skipped when it actually exists. With an unreadable size the two candidate offsets are content-probed with the host's method-stream plausibility test and an ambiguous result keeps the status-quo pairing. This removes the off-by-one that fed wrong push pages to the pump (content-rescue crawl).
* guest-diag: drop the fixed +1 vmap pairing (allocation-dependent)Arthur Hanson Rasmusson3 days
| | | | | | | | | | | The +1 vmap pairing was content-validated on one boot's CE push-buffer allocation (4097-page vmap: five rescue anchors at k+1), but r116/r117 show the leading header page is not universal: with the shift applied client #1 stalls mid-run (rescues resume) where it was green without it. Reverting the shift restores the previous behaviour; the kernel-side repair from 16124929 stays (a content-validated rescue replaces the injected pair, so a wrong pin is corrected once per page instead of being re-rescued on every pass).
* vgsp-sema: pair CE push-buffer vmap pages with the right offset; validated ↵Arthur Hanson Rasmusson3 days
| | | | | | | | | | | | | | | | | | | | | | | | | | | rescues repair injections The CE push-buffer uvm_rm_mem is vmalloc'd as a 4097-page area: one leading page plus the 4096-page (16 MB) GPU data window, so GPU data page k lives at vmap page k+1. The kcore chain resolver paired page k with vmap page k, pinning the adjacent push for every page; the pump then read the wrong push, decode failed, and the host fell into the content rescue which crawled one entry per ~2 s (r115: rescue_run=4202, entry_va=0x12001b18c repeating). Verified against five independent content-validated rescue anchors (k=20..28, all delta +1), and the vmap area boundary confirms the extra page (nv_vm_map_pages 4097 pages). Five fixes: - resolve_mem_pins() takes page_off; the CE chain and uvbp push-buffer paths pass mem_page_off() (1 when the vmap is exactly 16 MB + 1 page; 0 for direct-mapped mems like the semaphore pool). - a content-validated rescue page now also replaces the injected-pin entry (svc_rescue_try / svc_rescue_run_try), so a stale or wrong injection can no longer shadow the validated page and re-run the rescue on every pass. Evidence: r115 rescue anchors va 0x120014000->pa 0x12a2e2000 .. va 0x12001c000->pa 0x12a2de000 all at vmap offset k+1; the candidate pages decode as the adjacent push (wrong semaphore payload) before the fix.
* guest-diag: stream the newest client and seed the CE chain from uvchArthur Hanson Rasmusson3 days
| | | | | | | | | | | Two robustness fixes for the sequential client battery. cdt_pid() now picks the highest-pid CUDA candidate: preferring a name-prefix match kept the scanner pinned to a previous client that was still tearing down while the new client had already started pushing, so its first pushes were unreadable, the release expectation drifted past the real payloads and the stall followed. The CE push-buffer chain resolver now also runs for uvch channel kptrs, so the pins do not depend on the uvmt semaphore events alone.
* vgsp-sema: resolve the CE push buffer from the kernel chain (second-client ↵Arthur Hanson Rasmusson3 days
| | | | | | | | | | | | | | | | | | | | | | | | stall) The second CUDA client's GPFIFO entries in the CE push-buffer window (0x120000000) had no injected pin: that window is never mapped into the client's pagemap, so the scanner's window scan cannot see it, and its only supplier - the one-shot uvbp kprobe event - is raced by two trace clears (the scanner's pid-switch clear and semfix's trace-tail clear). When the event loses the race the entry reads fall back to the ~250 ms content rescue, which is the second-client stall and the same resolution-miss class as the ISSUE-0001 lottery. The guest scanner now walks channel->pool->manager->pushbuffer->rm_mem in kernel memory with kcore and pins the push-buffer pages directly (no trace event to lose), and the trace reader's dedup marks reset on a client switch so a reused kptr cannot suppress the new client's #pb. Boot evidence (r112): rescue reject ipin=0 for va_page=0x120023000, rescue scans 175 ms - 1 s each, want incrementing to 39. Smoke test of this fix on the stalled VM: 478 pin runs (~7955 pages) streamed within seconds, first va=0x120000000 -> pa=0x108090000. A bounded kernel log now prints the first CE push-buffer pins of each session.
* vgsp-sema: drain the injection queue immediately before the GR fill ↵Arthur Hanson Rasmusson3 days
| | | | | | | | | | | (second-client zeros) The watcher's pins for the second client's a/b/c buffers can land between the service loop's svc_handle_map_add() and the launch capture; the fill then misses them via svc_ipin_lookup, resolves 0 pages, relocates nothing, and the win0 param page keeps the driver's guest VAs (rk1: candidate[0..2] -> 0 new pages; DIAG win0[0] 160=753e4ec00000). Drain the queue right before svc_gr_req_fill() (same service thread, no race).
* vgsp-sema: re-arm ring/push-buffer discovery latches on channel ↵Arthur Hanson Rasmusson3 days
| | | | | | | | | | | | | | | | | | | | registration; scanner streams anonymous high-VA buffers Second-client wedge fix: a new GSP session re-registers the same channel handles/ranks, but the per-rank one-shot ring/push-buffer discovery latches stayed set from the previous session, so the new session's ring was never re-autopinned (ring_auto=0 pb=0/0, nomap growing) and the guest spun in its channel-creation wait. svc_chan_rearm_rank() clears the latches on every channel registration; all post-fix cycles launch the second client. Scanner: guest_pin_stream.py now streams the client's anonymous high-VA mappings (cudaMalloc buffers were skipped by the old len(parts)<6 check), so the host can learn their pages. Diagnostics: PT-window lines, per-window first words, post-OK qmdwin w48..59. Remaining: the fill-time svc_ipin_lookup miss for the second client's a/b/c pins (they exist in the pin log but are not seen at fill time) - next session.
* vgsp-sema: a stale-dropped pool read must not consume the residue rule ↵Arthur Hanson Rasmusson4 days
| | | | | | | | | | | | (second-client fix) r99/r100: the fresh session's reused pool page reads the previous session's residue (cur=2) before the first genuine release (pay=1) is translated; the translated read set ch->pool_rel_seen, so every later residue release (payload <= cur) was silently dropped by the final else and the client spun at DEVICE forever. A read that applied or deferred nothing now leaves the flag clear so the r63/r64 residue re-seed still fires for the first genuine release of the session.
* vgsp-sema: discover GR data candidates from the fresh inline param block ↵Arthur Hanson Rasmusson4 days
| | | | | | | | | | | | | | | | (second-client fix) Second-client launches scanned a stale/reused guest param page that still held the FIRST client's device VAs: zero new candidates resolved, nothing was relocated, and the engine executed with unrelocated guest pointers (r97 evidence: client#1 '15 candidate ptrs, 100 pages resolved' and win0 param 160=110400; client#2 '12 candidates, 1 page' with 160=75552ec00000 unrelocated). The driver-authored inline param block is captured from the pushbuffer at request time, so scanning it makes pointer discovery independent of guest-page reuse timing. Adds svc_gr_scan_cand()/ svc_gr_scan_inline() and the DIAG win0/guest-param proof line. Client #1 stays green (4 cycles); the remaining second-client stall is the pool semaphore residue (see next commit).
* site: repository links use cgit tree URLs; external repo-link auditArthur Hanson Rasmusson4 days
| | | | | | | | | - titles.json: map relative doc links to https://git.vgpu.io/open-iov.git/tree/... (the host runs cgit; /blob/ URLs do not exist) - check_site.py: verify every git.vgpu.io URL on every page resolves (HTTP status check, cached, with backoff) - site pages: repository home links point at the .git/ URL - .publish-manifest.json: revised revision records
* site: open-iov.org 2026 documentation updateArthur Hanson Rasmusson4 days
| | | | | | | | | | | | | | - tools/site: Markdown-to-MediaWiki converter (tracked-paths-only link mapping, local-marker scan, About-message insert), WikiBot publisher with diff/check modes and publish manifest, live site auditor, image uploader, site-only page sources (landing page, About, index, sidebar, banner templates, About-message template). - wiki: new public deep-dive sources (project status, install, FAQ, system overview, GSP and GSP-RM, execution frontier, host module, guest stack, UVM, physical backend, driver lifecycle, risc-v-gsp-rm-debugger, hardware/software matrix, HAAEEP, glossary); refreshed CUDA userspace status; corrected cross-document links; README rewritten for the new set. - wiki/.publish-manifest.json records each published revision for rollback.
* cuda-ab: soak.sh client list env-overridable (SOAK_CLIENTS); smiley last by ↵Arthur Hanson Rasmusson4 days
| | | | | | | default smiley (cudaMallocManaged-class, known-failing until the param-offset fix) moved last so a baseline pass exercises the other 13 first.
* cuda-ab: victory-series coverage battery (8 new clients) + soak runner listArthur Hanson Rasmusson4 days
| | | | | | | | victory_saxpy, victory_reduce (shared+atomics), victory_matmul (tiled shared), victory_strided, victory_memset2d (pitched), victory_atomics, victory_streams_events (3 streams + events), victory_math (mixed int/float/double). Each verifies via readback and prints STATUS OK|FAIL. soak.sh now runs the full 14-client set (seq or sustained).
* vgsp-gr: dump first words of changed bounce pages (m142 diagnostic)Arthur Hanson Rasmusson4 days
| | | | | Discriminates engine-side writes of float data (kernel ran with c on this buffer) from non-kernel writes (pointers/QMD-shaped words).
* vgsp-gr: log the changed bounce page indexes at copy-out (m142 diagnostic)Arthur Hanson Rasmusson4 days
| | | | | | | 8 changed pages x 4 passes for smiley vs 33 for victory's vadd - the indexes name the relocated range (bi >= 0x40 = the c-pointer output window 0x150000+) and discriminate engine-side partial dispatch from a guest write-back/read attribution failure.
* vgsp-gr: one bounded re-arm of a stalled forwarded launch (context ↵Arthur Hanson Rasmusson4 days
| | | | | | | | | | | | | | | | save/unload lottery) r90 evidence: the 3rd session's forwarded launch entered SKED (CWD VALID) and was then saved/unloaded by the FECS before dispatch; qmd_rel stayed at 5/6, GP_GET froze, and every later launch on the boot was never fetched either. The service owns no repair path, so the channel stayed dead until reboot. On the first poll timeout, re-issue the two GPFIFO_SCHEDULE controls the stage-4 sequence used (channel-level 0xa06f0103 + TSG-level 0xa06c0101, both proven accepted) and re-ring the work-submit doorbell, then poll one more full window before the postmortem. No BIND, no PROMOTE (m76-m81 proved the explicit PREEMPT/tail variants stop the QMD enqueuing).
* vgsp: GR data path - pre-publish bounce fill, engine-change proof, ↵Arthur Hanson Rasmusson4 days
| | | | | | | | | | | | | | | | | | | | | | ipin-first data resolution Two fixes and one diagnostic for the all-zero-results class (r89: smiley's 4 vadd launches reported GUEST GR LAUNCH OK yet every output word read 0): - gsp_phys_booter: copy the guest data pages into the bounce window BEFORE gsp_phys_rmcall_publish_locked() rings the doorbell. The fill used to run after the kick; the engine front end starts within ~7 ms, so the kernel could read the window before it was filled. - gsp_phys_booter: per-page checksums at copy-in, compared at copy-out; the copy-out log now reports 'N changed by engine'. An all-unchanged window after a reported completion is the front-end-ran/grid-never- dispatched signature (completion semaphores are front-end authored). The first 3 data (va,hpa,reloc) triples are logged per launch. - gsp_sema_service: svc_gr_data_fill resolves data pages through svc_ipin_lookup() first (guest-truth pins), falling back to svc_resolve_va, mirroring the pool resolver order; a wrong page here silently runs the kernel on zeros. First 16 resolved (va,pa,ap) triples are logged for post-mortem comparison against the guest's own mapping.
* guest-diag: semfix_watch read64 uncached by default (stale-cache pool-pin ↵Arthur Hanson Rasmusson4 days
| | | | | | | | | | | failure) The watcher's resolve_sem_pool read sem->page->mem->vas through a process-lifetime cache: a transient zero captured while UVM was still initialising the structures was served forever, the pool pin never landed, and the second-session client hung in cudaMallocManaged (r88 evidence: 'pool unresolved (retry)' from the watcher while the same walk succeeded from a fresh QMP client). Cache is now opt-in.
* guest-diag: scanner EOF guard + exclude non-client nvidia fd holdersArthur Hanson Rasmusson4 days
| | | | | | | | | Two failure modes found when the scanner detects clients by device fd: a transient boot nvidia-smi was picked and its exited pagemap read back EOF, and scan_window advanced by got=0 forever (busy spin, no stream); and non-client nvidia fd holders must never be committed to. Break on got<=0 in scan_window (scan_range already did), skip nvidia-smi/ persistenced/Xorg, and prefer /dev/nvidia-uvm holders.
* guest-diag: scanner detects arbitrary CUDA clients by nvidia fdsArthur Hanson Rasmusson4 days
| | | | | | | | | | The guest pin scanner only tracked processes whose comm matched CLIENT_PREFIXES (cdt,va,victory). An arbitrary CUDA binary (e.g. /tmp/smiley) was invisible: no pages streamed, no VA->PA pins injected, the service could not read its pushes and the client hung in cudaMalloc/uvm_tracker_wait. Detect compute clients by the CUDA device they hold open (/dev/nvidia-uvm preferred, then any /dev/nvidia*), with the prefix match kept as the first-choice path.
generated by cgit v1.2.3 (git 2.39.1) at 2026-10-15 22:09:05 +0000