summaryrefslogtreecommitdiffstats
path: root/kernel/gsp_sema_service.h
Commit message (Collapse)AuthorAge
* vgsp: sema_gl_mme_keep_mask (u64, slots never stubbed/dropped), MME-PRE-DUMP ↵Arthur Hanson Rasmusson18 hours
| | | | one-shot (raw words+sa_mask+IR coverage), SA data-port capture (0x120 runs), gsp_sema_mme_code_words_get - offline MME64 sim proves macro(0) loads CB offsets (0x238c<-0x320 etc) and macro(2) binds vertex streams with observed args, no poison; live A/B keep_mask works (dropped 115 vs 181 words); r1146 boot beef did NOT retire (timeout 2500ms, elapsed 8842ms, 0/902 pages) vs r1144 94us retire - re-establish r1144 state (prelude 901 vs 773 words, pages 7 shadow 6 vs 8/5, warm-sem wedged) then rerun keep 0x4/0x1 - SESSION 153 r1145-r1146
* vgsp: stub IR write real encoding SEC_OP_ONE_INC=5 (op=1 walked ↵Arthur Hanson Rasmusson19 hours
| | | | 0x114->0x118/0x11c/0x120 clobbering SA[0]=1 = r1131 MISSING_MACRO_DATA), stub PC at IR-end, byte-exact END body, coverage-aware stubbing, ONE_INC ghost CALL fix (18->6 real), MME-WINRUN dump, prelude latch keyed (generation,h_object); mme_ir_end/ir_cov bitmap + USERD adopt latch clear - ATTRIBUTION ANSWERED: non-retire is NONE of the attachments (window-only also ILLEGAL_OPCODE 0/901; all-macro-noop sa_stub_all=1 still ILLEGAL_OPCODE 0/902); r1111 retire was a different frame class (5016B no-CALL) vs draw-class (7148B CALL_MME_MACRO(0)); next: MME reg sample BEFORE WEDGE-RECOVER reset + stub landing verify (stub_pc 0xf0 test) - SESSION 153 r1132-r1141
* vgsp+diag: SA-RAM table captured unbounded (entry[64], sema-mme-sa log), ↵Arthur Hanson Rasmusson24 hours
| | | | surf geometry accessor + completeness recs, fill seeds RT candidate 0 full span (<=1024 pages, completeness only on fully-resolved run); MME slot stub (called-but-uncaptured slots end-noop IR 0xC0, sema_gl_mme_sa_stub=1), reloc prefers tracked rec bounce VA; pin family += 0x4200000 - 0x238c wall root-caused (capture truncated buffer full=28 words=512, SA[0x22]=0 jump IR 0; sim proves slot-0 emits EMIT 0x238c=0x20020); fixes never executed (setup-push read lost, unreadable=1 first8=00040000 00001000); next: trustworthy pagemap resolve or accept ipin first-chunk - SESSION 153 r1117-r1120
* vgsp: SURF-PRELUDE (replays captured C597 colour-target bind ↵Arthur Hanson Rasmusson25 hours
| | | | alias-scanned+pair-relocated ahead of targetless stream3d windows - the NO-STORE cause: windows carry no render target; emitted words=7 window=391), ATTR sanitize (drops active attr words with width=0; r1113 torn 0x81a4 fixed), MME-miss census into MISS-ABORT+demand, MME-IMMATURE-SKIP; r1116: draw reaches engine, trap moved to 0x238c LOAD_CONSTANT_BUFFER_OFFSET Data=0x20020 then PBENTRY; GATE 1 static nz=2551 mean=0.083 DIFF 0 - SESSION 153 r1112-r1116
* vgsp: PBENTRY first-sighting watch (all 12 PBDMA intr0 bit18, ↵Arthur Hanson Rasmusson27 hours
| | | | PB_HEADER/COUNT/DATA0/HDR_SHADOW dump pre-rearm, 8/boot) + PB-FAULT-DUMP voff/tail/past-end; sema_gl_sdm_drop (op-0/2/6 single-word SDM entries from preludes+window); reloc level-2 fallback; sema_gl_miss_abort (pre-doorbell abort on residual MISS, feeds pin demand); gsp_sema_demand_note + attr-prelude ptr pages demand-recorded + sema_attr_settle_ms=8000 - **FIRST BEEF WINDOW RETIRES ON REAL HW** (poll break ch=0xc0ffee02 after 68us, 737-word block) but no-store retire (0/4 pages changed, NO-STORES); residual MISS flood (miss=11..17) blocked by FULL demand set (64/64 MAX) - SESSION 153 r1103-r1106
* vgsp+diag: attr/pipeline prelude (families 0x1100-0x1200/0x2000-0x2060, ↵Arthur Hanson Rasmusson28 hours
| | | | dedup, 512w, program-pair VA record; emitted via patch_window relocation, run-aligned after MME prelude), mature-prelude gate (>=64 0x114 code words, sema_gr_prelude_gate_ms=60000 busy-defer), pin_gr_stream 0.75s pass, trap regs in sked sampler - first clean DS+MME (ds_esr=80000000 mme_esr=80000000, a2040a00 gone); 0x1168 CLASS ERROR persists as MME-MACRO-GENERATED WRITE (no 0x1168 header in emitted stream; macro(2) args [0,0,600000,0,610800]); next: disassemble macro (2) at pc 0xa + trapped-addr read pre-latch - SESSION 153 r1095-r1100
* vgsp: sema_gr_setup_hold_ms param (default 0) - setup-push detect (>=12288B ↵Arthur Hanson Rasmusson30 hours
| | | | or MME-setup families in scan), hold arm on first unreadable read with 8x4K demand to stalled-VA channel, deadline consult at consume gate; r1079-readable setup captured words=511 (contrast r1083/85/87 zeros = setup-push read lottery root); hold fired but guest resolver covers only 0x120000000-0x121000000 - next: extend resolver to GL pushbuffer VA families - SESSION 153 r1083-r1087
* vgsp: MME setup prelude - capture client MME context-setup runs ↵Arthur Hanson Rasmusson31 hours
| | | | (0x114..0x124/0x234/0x550..0x568/0x3400..0x34fc) verbatim, exact-run dedup, 512-word buf + gen counter (sema_mme_prelude_cap); one-time-per-generation preplay in GR launch build (sema_gl_mme_prelude); capture verified - full macro program 11 SA/IR pairs ~206 code words, MME-PRELUDE emitted gen=5 words=444; no further mme_esr=80000004 after prelude (r1079); remaining: setup push unreadable=1 skip before pin demand; r1082-class content-independent dispatch stall - SESSION 153 r1078-r1082
* vgsp: xw-mirror page-reuse guards + submit-status clearer scaffold (SESSION ↵Arthur Hanson Rasmusson4 days
| | | | | | | | | | | | | | 148 r873) The unguarded 3 ms mirror loop kept writing the count law into its latched page after the guest had reused it (r872 evidence: guest 'Bad page map ... pmd:102656067' pointing at exactly the mirrored page's PA as another process's PTE table). The loop now latches the progress word's base bits and stops permanently when they change or are zeroed, and re-checks the counter object's signature every 64th tick. New sema_xw_comp parameter + vgsp-xwcomp kthread can clear a submit member's armed 0x8000 status (value 0 pattern only); r874 proved an unverified clear into a false member kills Xorg within seconds, so it stays uninjected until the member address is watched live.
* vgsp: X/GL frame-pacer mirror (sema_xw_mirror) - unblocks the 10s/frame stallArthur Hanson Rasmusson5 days
| | | | | | | | | | | | | | | r861 evidence: the X server's present path spins in a 10s-timeout wait ((EE) NVIDIA(GPU-0): WAIT (2, 8, 0x8000, <stuck 0xd4..>, <driver counter +0x70/frame>)) comparing (progress_word & 0x3ffff) << 2 against its own submitted-byte counter; the progress word (lone u32 0x140235 in an otherwise-zero guest page) never advances because the emulation does not execute the 2D method streams -> glxgears 0.09 FPS. A gdb write of the word to 0x140000 | (counter >> 2) made the wait complete in 3 ms (WAIT (0, ... <equal>, <equal>) immediately after the timeout print) and silenced all further timeouts. This adds a 3 ms kthread that mirrors the driver's counter word into the progress word; both guest PAs are injected per boot via the sema_xw_mirror parameter (0,0 stops). Demo-path tuning aid; no product logic depends on it.
* vgsp: client-session boundary fixes - WD ring scan gate + forced session flushArthur Hanson Rasmusson5 days
| | | | | | | | | | | | | | | | | | | | | | | Two changes from the r839/r840 multi-client forensics (session 147): 1. The guest-RAM content scan for a GR ring must not run for the kernel RC-watchdog channel (h=0x31415900). Its ring is a plain kernel allocation always resolvable through the driver-published VAS walk; on r840 the walk lost a registration race, the scan latched a foreign garbage page, and the bad latch poisoned the driver's DMA test ('Failed to initialize DMA', Xorg died). Gated, the walk retries per pass; r841 Xorg#1 passes DMA (DMAFAIL=0) where r840 failed. 2. sema_force_flush module parameter + gsp_sema_service_sess_flush_force(): execute the ISSUE-0002 client-session flush even with live channels. The channel-close trigger never fires on real boots (driver-global channels stay valid), so later client sessions inherited stale discovery state. Verified on r841: flush executes mid-boot, Xorg survives it and re-registers its channels. Remaining wall (addendum 9): GR client channels' pushbuffer reads return all-zero through the trusted translation (va=0x4000000-class, src=4), so first entries never complete and GL clients never render.
* vgsp: channel-scoped VA resolution via the channel's own VAS (r835)Arthur Hanson Rasmusson5 days
| | | | | | | | | | | | | | | | | | | | | | | | | | Every RM client maps different objects at the same numeric VAs (all clients' windows sit at 0x1200xxxxx), so the global VA-keyed pin/lat/map layers conflate them across clients. Live walk_probe evidence (r834): the X server's ring VA 0x120090000 resolved through the GL client's page tables (vas h=0xcaf00005 -> a zero page) while the X client's own VAS (vas h=0x10005) holds the real page (pa=0x1294fa000). That conflation is what wedged the X server's readback wait and starved the RC watchdog's ring (its pushes decoded as empty). * Parse NV_CHANNEL_ALLOC_PARAMS.hVASpace (@28; layout confirmed by the struct's own known offsets) at channel registration and carry it on svc_channel. * svc_chanvas_lookup: resolve a VA through the serviced channel's own VAS page tables first (svc_cur_vas, refreshed per channel turn and in the decode path). The hook sits at the head of svc_lookup_trusted, so ring, push, release and notifier resolution all inherit it; a failed walk falls through to the old chain unchanged. Live r835: X's XShmGetImage readback, previously never completing, returned after its long wait and a frame reached the kvmfr BAR (first frame content still black and readback latency still ~87 s; the guest-side fbcopy_pub framebuffer reader tool is added for the direct-VRAM capture path, find/pub/test modes).
* vgsp: X/GL wall broken - PROMOTE_CTX registry, small trusted-NOP acceptance, ↵Arthur Hanson Rasmusson5 days
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | push-scoped release deferral The X server now starts on the emulated vGPU and GLX runs on the real NVIDIA driver: Xorg :0 passes its DMA sanity push and ScreenInit, and DISPLAY=:0 glxinfo reports 'OpenGL 4.6.0 NVIDIA 570.144' with direct rendering; GZDOOM 4.14.2 launches and renders. Before this, every X start died at 'NVIDIA(GPU-0): Failed to initialize DMA' (the __nvPushTestPushBuffer 10 s GP_GET wait) and no nvidia-push kernel buffer could be resolved. What each piece fixes (all observed live on the r817->r827 cycles): - sema: register the driver's PROMOTE_CTX context-buffer statements as a VA->PA registry, consulted as the LAST resort after every walk. A promoted (va, pa) pair is a VA-space booking, not a mapping: its span can swallow other buffers' VAs (the ctx MAIN booking covered the channel GPFIFO VA and range arithmetic answered the entry validation with MAIN.pa+offset, a zero page - the latch never fired, r823), and even its base page can host a separately mapped buffer (the PATCH booking's base VA hosts nvidia-push's 4 KB progress semaphore; the release landed in the booking's page while the driver's own polled page stayed zero, r826). The walks describe the real mappings and must answer first. - sema: an all-zero GR push of <= 16 bytes resolved by the trusted chain (src=4) is accepted as the driver's NOP sanity push (NVA16F_DMA_NOP is a single zero dword; real launches are hundreds of bytes). The r496e acceptance required a content-scanned ring, which the X/GL channel is not. - sema: the wave-1.5 release deferral is push-scoped. A release whose push owns no captured forward candidate has nothing to wait for; it applies inline (the progress-tracker semaphore release used to be recorded and dropped at every pass reset while an unrelated lingering candidate armed the global defer). - sema: the m164 no-capture hold no longer arms for the accepted zero NOP - it held the NOP entry for its 6 s window 'forcing capture' of a launch that cannot exist. - sema: once the ring resolves, the USERD latch scan may retry past its 8-scan cap (the client's VAS directory registration lost the race against the 10 s DMA window when a rebuild stretched the pass cadence, r820). - sema: dbg-gated USERD-scan decision witnesses (rejection reason, sweep summary, per-call state), GR-only and budgeted. Known next issue (not this change): sustained X/GL rendering traffic wedges the guest RC watchdog ('NVRM: krcWatchdog_IMPL: GPU is probably locked') after minutes of GZDOOM/GLX activity; the FIFO service itself keeps consuming.
* vgsp-sema: bounded channel rewind (sema_chan_rewind: hex h_object or 'all' ↵Arthur Hanson Rasmusson7 days
| | | | -> clears slot_done_epoch + last_get + the per-entry rescue state so entries skipped before the VAS pdb anchor re-decode) + bounded per-chunk push-read failure witness (sema-pushfail: va/chunk/page/last_rc/trusted_rc/ipin/alt/win per failed chunk); wall2: runbook.py (trigger the anchor then rewind). Session 118: the anchor+rewind path is wired; the automated rewind scheduler missed (dmesg churn) and the pushfail trace still needs one clean capture
* vgsp-sema: host-triggered VAS pdb discovery (sema_pdb_discover va,pa -> ↵Arthur Hanson Rasmusson7 days
| | | | verify the parked COPY_SERVER_PDES candidates against a content-verified ring pair, then fall back to the vidmem walk-root sweep) + runtime-tunable candidate age-out (sema_vas_cand_ms; the default 15 s ages the client's VAS candidate out exactly when its channels first register, so the verified walk can never anchor it by itself)
* vgsp-sema r616 diag: grfaultpoke - manually write a channel's error notifier ↵Arthur Hanson Rasmusson8 days
| | | | (relayed-fault shape: info32=except, info16=engine, status=0xffff, notifier_err latch) and post its channel event, to test whether a synthetic engine-error edge ends a refused launch's cudaDeviceSynchronize spin (the authored sw release lands - measured 0x6 - but the kernel never completes for a never-executed launch)
* vgsp-sema r609: age the device-dst guard per channel burst - the r606 ↵Arthur Hanson Rasmusson8 days
| | | | | | | | | | | | | | | | | | | | | | | | | | held-chain serialization The m169 device-dst first-touch window is per PAGE, but the risk it covers is per client table build. The driver's H2D relocation burst on the eng==0 copy channel writes N distinct first-write pages back to back; because the pump holds the first held entry and the rest of the chain decodes only after it drains, each page paid its own 3 s window, serialized (r606 red draw: hold idx=90 362167.7->362170.8, idx=92 362177.7->362182.9, the b H2D entry ran 362182.882, 326 ms AFTER the launch forward -> VADD bad=32735 csum=8139264, c = a + 0). Every observed release logs 'without a pin': the pin the window waits for never arrives for this class. After ONE un-pinned release on a channel, age it (gsp_sema_copy_dst_age_ms, default 3000): further first-write device-dst pages of that channel inside the window run immediately with the walk translation - the exact translation the expired guard would have used anyway. The first page of every burst still pays the full window; only the N x window serialization is removed (~20 s of chain -> one window). Keyed by h_object like every channel table and cleared by the session flush (svc_dst_guard_reset; also clears the per-page slots, which are keyed by VA alone and must not pre-age the next client's first touch - the r604 lifetime lesson). 0 restores per-page windows (pre-r609).
* vgsp-gr r598 diag: peek the ring slots past GP_PUT at the launch decisionArthur Hanson Rasmusson8 days
| | | | | | | | | The r568 lever is the driver's ring WRITE pointer, not the GPFIFO put: the b copy entry exists in the ring before the client publishes GP_PUT. Add a bounded diagnostic (gsp_phys_gr_peek) that, when a channel reads as drained, dumps up to four slots past last_get with {va,len} and whether the slot already executed that exact entry - so the next fix can be grounded in what is actually written ahead of the put.
* Revert "vgsp-gr r595b: bound the stream-order guard to a settle window, then ↵Arthur Hanson Rasmusson8 days
| | | | | | forward (never refuse)" This reverts commit 9333e84deed78464a7448c9faaf6841261a802d8.
* vgsp-gr r595b: bound the stream-order guard to a settle window, then forward ↵Arthur Hanson Rasmusson8 days
| | | | | | | | | | | | | | | (never refuse) With r595 the relocation copies execute within 0.5-1.5 s, but the r590b watermark deferred through the shared 15 s cap; by then the r541/r583 dstpend guard took its fail-closed branch and refused a launch whose data was already on its way (r596 mail MAILDUMP zeros, 2 refusals). Track the settle start per push VA and defer only for gsp_phys_gr_cewm_settle_ms (default 2000). Each deferral is one pump pass and the pump drains the copy rings before the launching channel, so the window is enough for the r595 copies; after it the launch forwards with a witness. The guard can no longer reach any cap-refusal branch.
* r576 diag: launch-decision + event-post payload witnesses ↵Arthur Hanson Rasmusson9 days
| | | | | | | | | | | | | | | | | | | | | (gsp_phys_gr_dec_log, gsp_rm_ev_log) The GR launch-decision dump logs, for the first N draws whose fill saw dropped pages / a partial argument set or whose decision point carries a dstpend/copy-pending verdict: the decision verdicts, the launch's resolved data pages (VA -> guest PA), the live deferred-write records and the pending CE opdef entries - the operand evidence needed to explain a red draw of the readback lottery (the wrong-but-similar page hypothesis). The event-post witness logs every EVENT_POST_EVENT record actually sent with its full payload (hClient/hEvent/notifyIndex/data) and send result, plus a sentinel when post_all_events found valid events but posted none while none were dedup-skipped. This is the evidence needed when a client parks waiting for a completion wake-up that never arrives (the 2nd-client device-state spin): it shows whether the post was generated, for whom, and whether the status-queue write accepted it or dropped it (burst cap / ring full). Both are inert by default (budget 0).
* r496j VAS candidates are registered only after a content-verified ring walk ↵Arthur Hanson Rasmusson10 days
| | | | | | | | | | | | | | | | | | | | (+3 fixes) The r496g blast registration of every COPY_SERVER_PDES directory let a stale kernel directory answer another client's VA in the walker's first-success order (the r459 stale-directory class) - measured as a CUDA client hanging after DEVICE. Candidates are now parked and registered only when a walk of the client's own content-validated ring VA through them reproduces that ring's PA; the r496f vidmem sweep remains as a fallback. Also in this batch: - svc_chan_userd's VRAM shape scan now prefers a block with work PENDING (get < put) and then the one nearest the registered memdesc offset: on a channel re-registration the stale previous USERD still validates (it holds the same put/entry values) and the old first-match adoption made the pump write GP_GET into the dead block (r504 second DMA init). - The USERD/FB scan and the CE caps byte-1 BL bits (r496i) are unchanged; TU104_CE_CAPS1 = 0x03 needs the CUDA battery re-verification.
* r481 sema_push_raw diagnostic: dump the decoded method stream of the first N ↵Arthur Hanson Rasmusson10 days
| | | | large GR-class pushes (default 0 off, no behaviour change) so the launch push's acquire/release method groups are visible verbatim; needed to prove which ordering mechanism the driver relies on for async-stream H2D -> kernel dependencies (streams_events st2 vadd copy-in ran ~115 ms before its stream's H2D soft copies)
* sema: r401 acquire-wait hold bound + session-wide exactly-once capture memoryArthur Hanson Rasmusson11 days
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Two fixes for the streams2 / multi-stream ordering class, both verified on fresh boot r401 with the acquire gate enabled: 1. sema_wait_hold_ms (new module param, default 4000 ms) replaces the hardcoded 100 ms acquire-wait bound in svc_run_ops. The old bound is shorter than one emulated GR launch completion (0.5-1.6 s observed), so a D2H readback's ACQ_CIRC_GEQ on the producer channel's progress counter (op=3 pay=4 on 0x20400ffd0) gave up and ran BEFORE the scale launch wrote d_c2; the client then verified pre-scale data (bad=32767). r401 log: the same entry now holds ~1.2 s across cur=1->4 and runs after GUEST GR LAUNCH OK (copy-back optrace 92315.594824 with dst16_after = the post-scale bytes). Fail-open is preserved: a genuinely unsatisfiable acquire still expires, just late enough that the dependency's work has landed (late-but-correct over early-and-wrong). 2. svc_gr_seen: a session-scoped open-addressed (push_va, hash) table behind svc_gr_cand_push_seen(). The 4-slot candidate ring + 8-VA history evicted a real capture within ~12 later captures, so a true replay of an already-forwarded launch was re-captured and re-executed (r399: the same nine launch pushes re-submitted every ~10-11 s for minutes). Cleared in svc_session_flush because a new client's identical-content pushes restart their release counters - a boot-scoped table would silently drop them (LAUNCH-SKIP). Also adds tools/cuda-ab/streams2d.cu: streams2 with per-array/per-4KB-block diff reporting plus the device pointer dump, which localised the remaining failure to the D2H staging write path (our staging-page resolution vs the guest's view).
* sema/boot: r391e print the shadow base pointer in the copy-out and bigcopy ↵Arthur Hanson Rasmusson11 days
| | | | | | | | | | witnesses Rule in/out a stale or duplicate vgpu->bars[1] shadow between the launch copy-out (svc_fwd_req.vgpu) and the D2H reader (svc_copy's vgpu): the sum=0 runs show the write landing (OUT-PAGE-POST val8 = the sum) and the reader of the same ledger page reading zeros 8 ms later with no logged writer in between. Diagnostic only.
* sema/boot: r391c OUT-PAGE-WIT resolution witness for the sum=0 readback classArthur Hanson Rasmusson11 days
| | | | | | | | | | The GR copy-out now prints, per changed page, the landing-table resolution of the VA (the exact source the D2H reader's ledger-first branch uses) and its first 8 bytes beside the write target hpa - a launch/readback disagreement (write landed on another page/aperture than the reader resolves) becomes one line instead of a forensics session. Diagnostic only (bounded by the existing copywit budget).
* sema: r384 fill-destination guards - pin-demand hold for large unproven ↵Arthur Hanson Rasmusson11 days
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | fills + page-table-shape refusal for zero fills (the boot-corruption lottery root-caused to zero writes landing on guest page-table pages) Forensics from the r383 boot (guest panic at t=216 during victory_strided): the guest kernel's direct map had TWO 2 MiB holes (phys 0x105000000 and 0x131800000) because their PTE pages at gpa 0x12d3c2000/0x3000 - two adjacent 4 KiB page-table pages - were found all-zero. Kernel objects (the kprobe nodes UVM registers at module load) lived in those regions; the first access after the zeroing faulted (Oops #1 get_kprobe from uvm_init_entry), cascading to the t=230 panic. The zeroing is an 8 KiB all-zero write, the exact shape of the guest's window page-table clear (LINE_LENGTH=8192, value=0), and the emulation's virtual fill resolver is demonstrably non-deterministic: four executions of that same 8 KiB fill resolved to four different guest pages (0x126af8000, 0x12d8e4000, 0x12f20c000, 0x1187fb000 - every one refused by the below-floor guard). The below-floor guard covers window VAs only; a >= 1 TiB VA fill that resolves through the walk/scan had no guard at all. Two nets in svc_fill, both default-on (sema_fill_guard=1) and both fail-open/histed: - net 1: a >= 64 KiB virtual fill whose only authority is the walk/scan (no pin, no landing-table entry) is held through a bounded 800 ms window (sema_fill_guard_ms) while its VA is demanded through the pin channel (the userspace pin stream injects the guest-pagemap truth), so the retried decode resolves through a real pin. Mirrors the m169/r378 copy guards; releases with the historical behaviour after the bound. - net 2: a ZERO fill about to land in guest RAM on a page whose first 64 qwords are all present+NX+in-range PTEs is REFUSED loudly (FILL-PT-REFUSED) - a page table page is never a legitimate zero-fill destination. Pin-backed resolutions are exempt (guest pagemap truth). New witnesses: FILL-HOLD (held fills) and FILL-PT-REFUSED (refused page-table targets), both bounded.
* sema/boot: r383 kill the blanket bounce copy-out (alias+staleness write ↵Arthur Hanson Rasmusson11 days
| | | | | | | | | surface) + write guards; REPLAY-CAPTURE closes the silent launch-drop hole; CE operand misses feed the pin-demand channel - bounce copy-out now records staged_hpa[bi] per launch and skips: (a) recs whose hpa != staged slot content (alias/leftover), (b) pages the engine did not change (~955 of 968 per boot launch); the remaining changed pages re-validate via gsp_sema_gr_write_guard before the 4 KiB memcpy. Removes the blanket 968-page write-back that was the remaining boot-corruption lottery vector (guest slab freelist clobbered by a foreign page write). - new bounded WGUARD-SKIP guards: gr_write_guard (pin-first re-resolution) on copy-out, release-word zero/restore (rel_va plumbed through the submit), stale-recover-zero, counter release; svc_write_guard pin-agreement on 4/8-byte SYS/FB service writes; svc_copy SYS-dst hold on a fresh-pin contradiction. - svc_qmd_accum replay hole: a trusted replay of an unseen push now captures (REPLAY-CAPTURE) instead of silently dropping; known push -> LAUNCH-SKIP witness; capture history ring prevents double-capture. - svc_op_translate miss path emits the stalled-VA demand signal for CE operands.
* sema: decode count=1 SET_REMAP_CONST A/B/COMPONENTS (the CE page-table fill ↵Arthur Hanson Rasmusson12 days
| | | | constants) + opt-in vidmem-window fill execution (gsp_sema_winfill, off) + FILL-RAW raw-push diagnostic; remapconst log budget 256
* gr: record the launch's resolved operand pages in the ledger - fixes the D2H ↵Arthur Hanson Rasmusson12 days
| | | | readback reading a stale page (victory_reduce sum=0 class); add GMMU walk trace + fwd-hpa diagnostics
* vgsp: C56F acquire wait gate as an opt-in experiment (default off)Arthur Hanson Rasmusson12 days
| | | | | | | | | | | | | | | | | | | | | | The streams2 readback-before-scale class is root-caused: core CUDA starts compute-channel pushes with a C56F SEM_EXECUTE acquire (ACQ_CIRC_GEQ on a tracking semaphore; e.g. the D2H readback push waits on 0x20400fef0 >= its sequence number) and the decoder ignored it, so the copy ran ahead of the scale launch it waits for. The gate implemented here (decode the acquire; svc_run_ops holds the push's work until the semaphore satisfies, with the driver's release(N)+acquire(N) same-push pattern treated as satisfied; op-pending bounded hold; kill switch at 2048 holds; diagnostics sema-wait held rows with a per-session budget) OVER-HOLDS on boots where a channel's first pushes wait on counter values only their own withheld release would install (wait counts reach thousands, the client stalls; r337/r338/r339). The tracking-semaphore value semantics (what the guest word should read vs the driver's sequence numbers) need a dedicated pass before this can be enabled. Default OFF so behaviour is the pre-r336 one; enable per-boot with sema_wait_gate=1 for the experiment. Everything else (pin-wins, vector_add, the battery) is unaffected.
* vgsp: fail4 r231 - READ-ORDER guard/witness + 32KB copy-resolution witnessArthur Hanson Rasmusson14 days
| | | | | | | | | | | | | | | | | | | | | | | | | | r231 probe: RAWA (fresh 64 KB upload -> straight D2H readback, no kernel) returned foreign deterministic content (0x437F0000-family ramps) where the uploaded ints 0..16383 must be, and PROBE2 == PROBE2B on that same content. The upload/readback round trip inside the emulation is therefore not content-preserving - before any engine execution. Two candidate mechanisms, both now witnessed: - READ-ORDER: a device-src copy reading a VA whose device-dst write is still inside the m169 pin-guard window (the writer's bytes land only when the guard resolves) - the read executes first. READ-ORDER-WIT logs the coincidence; with sema_read_order_guard=1 (new param, default 0) the read is deferred through the existing bounded-hold re-decode so it runs after the write. Opt-in pending an A/B proving no green regression. - RESOLUTION DIVERGENCE: the dst (H2D) resolution consults the ledger before svc_op_translate while the src (D2H) resolution does the opposite, so a stale ledger landing can make the writer and reader touch different pages. The sema-bigcopy proof (va->pa/aperture/provenance for BOTH sides) now fires from 32 KB (was 1 MB), so the probe-class copies are on record. Build green; module param registered and visible. (cherry picked from commit bfe5d295dd3922c0dbcd0bd1a29912a02acb58ec)
* vgsp: fail4 discrimination tooling - copy-out page witnesses + full-boot ↵Arthur Hanson Rasmusson14 days
| | | | | | | | | | | | | | | | | | | | | | | | | | | bigcopy resolution budget 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=<device VA> hpa=<guest PA written> first8/last8=<bytes shipped>, 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: GR late-resolve span cap + fill candidate superset + RELOC-GAP stage ↵Arthur Hanson Rasmusson14 days
| | | | logging
* vgsp: GR relocation completeness - resolve unmatched device-VA words via the ↵Arthur Hanson Rasmusson2026-10-18
| | | | landing resolver (RELOC-FIXED), param gsp_phys_gr_reloc_resolve default 1
* vgsp: GR fill hold param-gated (default 0: log-only, never hold); ↵Arthur Hanson Rasmusson2026-10-18
| | | | record-destroyer root-cause notes
* vgsp: GR fill hold - absolute deadline + expiry-proceed + dropped-page detailArthur Hanson Rasmusson2026-10-18
|
* vgsp: m178 GR launch reliability + diagnostics; tools: pin latching robustnessArthur Hanson Rasmusson2026-10-17
| | | | | | | | | | | | | Kernel: authorship instrumentation + swrel gate for in-flight GR release VAs; first-poll shortening + fast extended re-arm (params gr_retry_fast=1, gr_first_poll_ms=2500); per-attempt win0 bank recompute + shadow recopy in the outcome-retry loop; poll-break/deposit-readback diagnostics; C1-C10 sema diagnostics (crel-entry, relx, opdef-clear, walk, pub-adv, hold-fallback, busy-defer, CAND-OVERWRITE, inline recs); busy-defer hold instead of software-release consume; counter fast path; QMD word 48/49 skip. Tools: heartbeat thread, scanner-alive probe on reinstall, full periodic re-assert, #nopid handling, per-client reset fix (debounce), dead-pid drop, supervisor grace+threshold.
* vgsp: m177 pin-free self-sufficiency wave + tool hardeningArthur Hanson Rasmusson2026-10-17
| | | | | | | | | | | | | | | | | | | | | | (1) svc_session_flush keeps svc.direct_base (per-boot constant; the pin-free targeted scanner's gate/input) and a new gsp_sema_service_guest_reset() hook wipes boot-scoped discovery state on guest RM reload; (2) counter-page derive now takes the first READABLE source (vaspaces -> discovered -> targeted) instead of failing -EIO on a walked-but-garbage page, with one-shot diagnostics; (3) new m177c UVM ring-space directory discovery: content-verified (push_va -> push_pa) samples from the GR content discovery and CE push pairing feed a second discovered-directory slot (walks the 0x2xxxxxxx family), consulted by svc_walk_discovered; (4) GR channels now deliver withheld opdef sets at entry consume (normal tail and the stale-skip path) instead of waiting for the 10 s sweep; (5) host tools hardened: semfix_uvmt QMP reconnect + pid-generation dedupe + stale-sem eviction + post-success pin latch + heartbeats; pin_gr_stream accept timeout + guest-scanner reinstall backoff + restart loop + subprocess timeouts; new pin_supervisor.sh (heartbeat watchdog, capped restarts) wired into start_vm_keep.sh. Evidence: r194-r196 cycles; pool resolves src=trusted pin-free; ring dir 0x10801c000 found 4/4; row: 'rel-apply ... written' with tools up.
* vgsp: m169 stale device-destination guard (device-dst copies translated only ↵Arthur Hanson Rasmusson2026-10-16
| | | | by walk/RAM-scan are held until a pin confirms; r172 streams2_diag stream-1 H2D wrote through a stale walk entry while the launch read the true page) + session-scope the op-trace budget + bigcopy witness covers device-dst copies >=64KB
* vgsp: m163 lost-H2D copy integrity (drain injected pins before CE op ↵Arthur Hanson Rasmusson2026-10-16
| | | | resolution; hold failed device-copy ops) + m164 CLASS-2 GR no-capture entry hold + m165 pool release applies at fresh-pin time + m166 timeout-ladder warm-sem fail-fast; scanner: first-class pool VA resolution + periodic re-assert + demand routing
* vgsp-dual: stage B+C minimal per-mdev separation (G1-G3, G5, G6, G7, G8a)Arthur Hanson Rasmusson2026-10-15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Goal 1.0: two mdevs + two QEMU guests running CUDA simultaneously. Single-mdev behaviour is kept identical: the legacy guest-RAM record still serves the first/only open mdev, the channel table degenerates to the historical key, and the session flush fires at the same last-channel-closed transition. - G6: guest-RAM backing {file, path, ranges} per mdev (legacy record + up to 4 vgpu-bound records); debugfs gsp-phys-guest-ram accepts an mdev UUID as an extra first token and keeps the 4-token form; records released on mdev cleanup and physical release. - G7: gsp_phys_gpa_to_hpa_vgpu(vgpu, gpa, *hpa); NULL keeps the historical first-open resolution. Forwarding operands pass the request's vgpu; the single-guest boot-ladder pin passes NULL. - G1: the sema-service thread services every open mdev each pass. - G2: channel table keyed by (vgpu, h_object); per-guest ranks; counter/scrub/opdef/pump snapshot+writeback matches per vgpu; scrubber records per guest. - G3: per-guest session records drive the flush; the shared learned tables (staged G4) are only flushed when no guest has live channels. - G5: hold/abort keyed by (vgpu, handle); dead-owner guards on the hold resolution paths; single-inflight serialization kept. - G8a: guest-GPA pin refused while more than one mdev is open. Build: make -j8 clean success (vgsp.ko). No module load. See DUAL-REPORT.md for the per-item status and live-validation plan.
* vgsp-sema: author the PMA scrubber channel's progress (third-client scrub ↵Arthur Hanson Rasmusson2026-10-14
| | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Revert "vgsp-sema: scope channel deletion to the owning RM client (ISSUE-0002)"Arthur Hanson Rasmusson2026-10-11
| | | | This reverts commit f5961087aa17111c6cdb7f6641626c0c877eee6b.
* vgsp-sema: scope channel deletion to the owning RM client (ISSUE-0002)Arthur Hanson Rasmusson2026-10-11
| | | | | | | | | | | | | | | | | | | | | Handles are per-client, but the FREE path unregistered any channel whose numeric handle matched the freed object, with no client check. r77 root cause of the third-client pma scrub hang: the boot session's CeUtils scrubber channel (h=0x2, gpfifo=0x120064000, entries=4096) was unregistered when an unrelated class-0x2080 object with handle 0x2 in client 0xc1d00011 was freed. The guest kept using the live channel for the scrub; the service no longer pumped it, its pushes were never decoded and the channel-buffer finish payload (pbGpuVA+0x6c004) was never written, so scrubCheckAndWaitForSize polled forever (sysrq stack: ceutilsUpdateProgress -> channelReadChannelMemdesc). Channel registration now records h_client (the RM alloc header's client) and deletion matches (h_object, h_client); a missing client on either side keeps the handle-only behaviour. Re-registration keeps the counter/release slots only for the same (handle, client) pair. Live proof from the hung VM: sema_probe translates the finish-payload VA 0x12006c004 to pa=0x10f962004 aperture=ram - the word the guest polls is reachable; the channel was simply invisible to the pump.
* vgsp: guest GR forwarding backend and capture (gsp_phys_gr_forward, default off)Arthur Hanson Rasmusson2026-10-05
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 ce40bd872ea05776156a68afcc6d4571a0bbcad2)
* 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
* gsp-phys: relay verify hardening and counter exposure (default off)Arthur Hanson Rasmusson2026-10-02
| | | | | | | | | | | | | | - the work_relay state line now reports the real backend data-compare verify_fail plus a verify_transient count, distinct from the sema-service hold re-read verify_fail (previously the backend counter was dropped) - a relayed copy whose host-side compare fails is re-read and re-compared once after a short delay; a transient mismatch counts as success and only a persistent mismatch falls back to the software apply as before - the final-mismatch diagnostic now logs the semaphore target/payload/poll time, the first differing byte and 16-byte dumps of live dst, live src and a submit-time analysis material, flagging source mutation vs snapshot/dst - the fault no_event path logs the post reason/return All changes are behind the default-off relay path.
* gsp-phys: P6c C3 - relay forwarded-engine faults to the guest (default off)Arthur Hanson Rasmusson2026-10-02
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | New default-off gsp_phys_fault_relay: when a relayed copy times out, the GSP-RM status queue is drained and the first OS_ERROR_LOG (0x1006) recorded after the submission's doorbell is decoded (NOCAT corroboration), matched against the ladder channel's runlist/chid, and delivered to the guest by writing its channel notifier (info32=exceptType, info16=engine type, status=0xffff) and posting the channel event. A late-release recheck skips delivery if the engine actually completed, one delivery per hold, and the existing software fallback always runs first, so no release or data is lost. - pure decode helpers extracted from the status printers; prints unchanged - status-queue walks serialized with a mutex; unmatched 0x1006 records are no longer silently dropped - fault epoch snapshot at the doorbell prevents stale records from matching - fault counters and faults:/fault_relay: state lines - default-off gsp_phys_fault_inject debug knob forces the next relayed pair's source PTE to zero to produce a real engine fault - pump notifier latch prevents clobbering a delivered fault Live: injection run produced a real CE0 FAULT_PTE (0x1f @0x200000), decoded with errString, chid/runlist matched, notifier delivered, software fallback applied (applied+fallback==engaged), clean release; the guest RM reacted to the delivered fault by tearing down its channels (faithful semantics). Healthy control: faults all zero, relay requested=40 ok=40, smoke matched=64/64, clean release. Caveat: the auxiliary event post failed (no_event=1, no MSI-X) and the guest teardown means fault injection is not smoke-compatible; the parameter stays off.
generated by cgit v1.2.3 (git 2.39.1) at 2026-11-01 11:32:59 +0000