summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAge
...
* STATE-CURRENT: real-release rc=0 chain reached; execution backend is the ↵Arthur Hanson Rasmusson12 days
| | | | | | | | | | | | frontier - the per-push 8 s stall was pump bookkeeping (release-seen keyed on the unchanged tracker-semaphore VA; rewind replays returning to the CE grace path) - fixed; real-release init now completes in ~1 min - the content rescue now parses the real method encoding, so NON_INC-headed pushes validate and their releases land - the queued launch's module image reaches the emulated vidmem; execution on real hardware (docs/03-architecture/08 backend) is the next project
* sema-svc: detect a decoded release by count, not by the (unchanging) VAArthur Hanson Rasmusson12 days
| | | | | | | | | | | | | | The pump decided "this push carried a release" by comparing the last decoded release VA before/after svc_decode_stream. Consecutive pushes on a channel release to the SAME tracking-semaphore VA (UVM's tracker pattern), so every push after the first read as release-less: the entry was held for the full CE grace window (observed: exactly one push consumed per 8 s, gating the whole runtime init; the release itself had already been applied by the decode, only the pump's bookkeeping stalled). svc_rel_count now increments on every decoded release (host sem block, REPORT_SEM block, CE launch-DMA release) and the pump compares counts at all three sites (initial decode, rescue re-route, rescued-page retry).
* sema-svc: never re-process a GPFIFO slot already consumed in the put epochArthur Hanson Rasmusson12 days
| | | | | | | | | | | | | | | | | | | A pin-batch rewind replays recently consumed entries. An old entry whose rescue cannot validate any candidate then sits in the CE grace path - and because the client's put has advanced since, the replayed entry no longer matches any "new" expectation: it waits the full 8 s grace, blocking every later entry behind it on that channel. Observed live: the first push of rank 0 re-processed and skipped twice, 38 s apart, while eight later pushes queued behind it. The pump now marks each consumed slot in a per-channel bitmap valid for the current put epoch (cleared when put wraps, so a recycled slot in the next epoch is processed normally) and consumes a replayed slot immediately. Rewinds still refresh readable entries; they simply no longer resurrect entries that were already handled. Evidence: real-release watcher cycle, replay-after-put-advance no longer produces 'skipping stale entry ... after 8000 ms grace' for old slots.
* sema-svc: consume rewind replays and sweep-delivered CE entries at onceArthur Hanson Rasmusson12 days
| | | | | | | | | | | | | | | | | | | | | Two stalls serialized the runtime client's init into one 8 s CE grace window per push: - a pin-batch rewind replays recently consumed GPFIFO slots; re-examining a consumed slot runs the rescue and then holds it for the full grace window again (observed: the same VA 'skipped after 8000 ms grace' twice, 38 s apart). The pump now records each consumed slot with the put value it was consumed at (32-entry per-channel replay ring, persisted across passes) and consumes a replayed slot whose producing put has not advanced immediately. - the content sweep applies releases from RAM pages before the pump reads their entries, so the pool advances past the entry's payload while it is pending. entry_want (recorded on first examination) now detects that on both the unreadable-rescue and the readable-no-release paths and consumes the entry instead of waiting the grace window. Evidence: real-release watcher cycle, pool semaphore advances no longer gated at 8 s intervals once the replay skip engages.
* sema-svc: validate pushes with the full method encoding; deliver releases ↵Arthur Hanson Rasmusson12 days
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | the sweep already applied The runtime client's second push on each UVM copy channel starts with a NON_INC method (0x60080002, count 8) and its release method sits 0x50 bytes in. The stream validator accepted only INC (op 1) headers, so the readable page failed the plausibility gate and every content-rescue candidate for that VA failed the read-back validation - the client's tracking semaphore for the push never advanced and the runtime init parked. - one shared parser (svc_stream_parse) accepts INC/NON_INC (op 1/3), IMMD_DATA (op 4, header-only), ONE_INC (op 5) and END_PB_SEGMENT (op 7), and still requires an exact method boundary over the whole entry plus trailing zero padding - the strict end condition is what keeps the content rescue safe against firmware/allocator pages - svc_method_stream_plausible and svc_stream_full_ok both use it, so a real readable push is decoded directly and a rescued page validates - the decoder skips NON_INC/ONE_INC methods whole (including their data words) instead of resyncing word-by-word through the payload, which could misread data as headers and queue bogus work Follow-on: the content sweep applies releases from RAM pages ahead of the pump, so the pump's expected payload was already satisfied when it examined the entry; the CE grace path then held each entry for the full 8 s window before consuming it - one grace period per push, serializing the client's runtime init. The pump now records the expected payload when it first examines an entry (entry_want) and consumes the entry immediately once the pool advances past it, on both the unreadable-rescue and the readable-no-release paths. Evidence (fresh boot, real releases, watchers + kprobes, no fakes): cudaGetDeviceCount rc=0 in the runtime client, device-attribute walk proceeds, pool semaphores advance; before this change the client sat in the 0x20801702 service-interrupt loop for >6 min and never left device init.
* STATE-CURRENT: no-pin release delivery committed; real-release init reaching ↵Arthur Hanson Rasmusson12 days
| | | | | | | | device count - 6ec799c delivers UVM tracking releases without host-side pins - one real-release no-watcher cycle reached cudaGetDeviceCount success - cycles continue; execution backend remains the gating item
* sema-svc: deliver UVM CE tracking releases without host-side pinsArthur Hanson Rasmusson12 days
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The runtime client's registration stalled when no guest-side pin scanner was running: the content rescue refused to run before the pool semaphore was translated (its expected payload was unlearned), and unreadable CE entries were consumed after two failed rescues ~40 ms apart, dropping the client's wait. The push pages then could not be found within the entry's grace window. - rescue: drop the learned-payload gate (the matcher only needs the channel rank and the release shape); keep unreadable CE entries pending for sema_ce_grace_ms instead of consuming after a fixed attempt count - expected payload: re-learn from the pool whenever it advanced (a deferred release could land after the first read, leaving the expectation stale) - matcher: require the expected payload exactly and validate the read-back stream carries it, so a recycled page of an older push cannot be pinned - scan: descending full-range pass (the work allocations live in the high RAM block) plus a +/-512 MB near pass around the verified push-buffer base - releases decoded with an untranslated semaphore are queued and applied when the page appears (svc_pending_add on both decode paths) - a CE push that reads as a plausible stream but carries no release for the channel is re-routed through the rescue instead of silently consumed - new module param sema_rel_recover (default off): after grace + rescue, apply the channel's expected tracking value so the client's wait clears; counter-visible as releases_recovered, distinct from sema_fake_rel Evidence: fresh boot, real releases, no host watcher, no kprobes - the six UVM CE first pushes are found by content rescue, their releases applied, and the client reaches cudaGetDeviceCount rc=0 (it then waits for the third push, which this change routes to the rescue).
* STATE-CURRENT: no-watcher cycles iterating (module rebuilt from the ↵Arthur Hanson Rasmusson12 days
| | | | | | | in-flight edit) - three real-release cycles without kprobes/watchers; no textual result yet - frontier unchanged: real-release runtime init and the execution backend
* STATE-CURRENT: activity resumed - no-watcher real-release runtime cyclesArthur Hanson Rasmusson12 days
| | | | | | - fresh module per cycle without kprobes/watchers; early observation: a compute-channel entry stalls with a failure notifier - frontier unchanged: real-release runtime init and the execution backend
* STATE-CURRENT: runtime client reaches kernel launch; execution backend is ↵Arthur Hanson Rasmusson12 days
| | | | | | | | the next wall - runtime init rc=0 (cudaGetDeviceCount/SetDevice/alloc/HtoD/launch accepted) - fixed the legacy clock-domain probe replies that blocked runtime init - next: real-release runtime init and physical-GPU execution of queued work
* GSPRM CLK legacy controls: populate the domain queries the runtime clock ↵Arthur Hanson Rasmusson12 days
| | | | | | | | | | | | | | | | | | | | | | helper gates on The static CUDA runtime's device init failed with cudaErrorInitializationError even though every kernel ioctl returned 0: cuInit succeeded and then cuDeviceGetAttribute(ECC_ENABLED=36) returned CUDA_ERROR_NOT_FOUND (500). Tracing libcuda's clock-domain helper (libcuda+0xe8c410) shows it issues the CLK legacy controls 0x20809009/0x20809064/0x20809001 and bails with 500 when the replies do not carry the expected domain bits/entries; the dependent attribute getters (ECC_ENABLED, TOTAL_CONSTANT_MEMORY) then abort init. Reply to the three queries with the minimal fields the helper checks: bits 32|34 present in 0x20809009, non-zero domain entries at offsets 12/20/28/36 of 0x20809064, and a matching selector in 0x20809001. No frequencies are fabricated (all other fields stay zero). Verified in the guest with the stock 570.144 static-cudart vectorAdd client: cudaGetDeviceCount -> rc=0 (ndev=1), cudaSetDevice, cudaFree, three cudaMallocs and both HtoD copies all return rc=0; the client then parks in cudaDeviceSynchronize waiting for the (not yet forwarded) kernel launch.
* STATE-CURRENT: PD writes proven live; runtime client past registration; ↵Arthur Hanson Rasmusson12 days
| | | | | | | | canonical reply fix - page-directory entry writes captured and validated; 64/64 baseline stays - vectorAdd client now fails after registration in libcuda (rc=3), no kernel error - BAR-info canonical reply-size bug fixed; one cache mismatch remains
* guest-diag: PD-watch cycle (dst-keyed root-PD watch + park-time shadow dumps)Arthur Hanson Rasmusson12 days
| | | | | | | | Reproducible TASK 2 harness: fresh boot, sema_dbg=Y with sema_copy_dst=0x200000 / sema_copy_dst2=0x208000, cdt2 parked at CDT_CP_PAUSE so the root PD/PT pages can be dumped and walk_probe run while the client is live. Prints the offending write data (prov= names the translation layer) and the post-run walk state.
* GSPRM BUS_GET_PCI_BAR_INFO: reply the canonical 8-entry params structArthur Hanson Rasmusson12 days
| | | | | | | | | | The control is cacheable in the guest kernel (RMCTRL_FLAGS_CACHEABLE) and rmapiControlCacheSet validates paramsSize against the canonical sizeof(NV2080_CTRL_BUS_GET_PCI_BAR_INFO_PARAMS) = 200. We replied only 8 + 4*24 = 104 bytes, so every reply tripped NV_ERR_INVALID_PARAMETER in rmapiControlCacheSet (rpc.c:9998) and the BAR-info cache entry was never populated. Zero-fill and report all eight NV2080_CTRL_BUS_PCI_BAR_INFO entries (count still 4).
* STATE-CURRENT: quiet logging landed; baseline verified twice; PD-capture ↵Arthur Hanson Rasmusson12 days
| | | | | | | | task next - dmesg diagnostics gated behind default-off sema_dbg; 64/64 with a 520-line log - staging buffer kept resolvable via streamed pins; PD-entry capture remains - note the guest-side kernel fault observed in serial
* guest-diag: stream the client's high-VA UVM sysmem pages as pinsArthur Hanson Rasmusson12 days
| | | | | | | | | The DtoH staging buffer lives in the client's high-VA /dev/zero|nvidia mappings (e.g. devptr+0x3c00100), outside the scanner's fixed CE/GR windows; only the host's pagemap read can see it. The guest scanner now walks those VMAs and streams their present pages so the module pins them. run_cycle.sh learns the sema_dbg master switch (auto-on when any watch knob is set).
* sema-svc: gate per-push/per-doorbell/RPC tracing behind default-off sema_dbgArthur Hanson Rasmusson12 days
| | | | | | | | | | | | | | | | | | A healthy run left dmesg dominated by per-operation lines (sema-push, sema-lda, sema-chan rel-apply, sema-grce, DOORBELL/BAR writes, GSPRM per-RPC lines, the teardown garbage-element stream). Introduce the module parameter sema_dbg (default 0) and route every high-frequency diagnostic through it; the finer-grained watch knobs (sema_ops_log, sema_copy_watch, sema_copy_pat, sema_copy_dst, sema_copy_dst2) only take effect while it is on. Boot stats, channel registrations, pin events and state changes stay unconditional. Also carries the per-side translation provenance (op_tr_src, printed as prov= in the destination-window watch) and the 16 KB destination window used to observe the guest's page-table writes. Verified: fresh boot + full cdt2 smoke test (64/64, ALL OK) leaves a 520-line dmesg with zero per-push/per-doorbell/per-RPC lines.
* STATE-CURRENT: payload roundtrip 64/64 restored by the page-table ↵Arthur Hanson Rasmusson12 days
| | | | | | | | publication capture - the device-to-host destination now resolves; baseline green again in live runs - frontier/active-work notes updated: land the capture fix, then the runtime vectorAdd client
* STATE-CURRENT: baseline regression (DtoH destination translation) and the ↵Arthur Hanson Rasmusson12 days
| | | | targeted-fallback/retry work
* sema-svc: hold and retry a readable push whose operand is under a targeted ↵Arthur Hanson Rasmusson12 days
| | | | RAM scan (the DtoH dst staging VA needs multiple scan slices)
* sema-svc: operand resolver gains the targeted rm_mem fallback; per-side ↵Arthur Hanson Rasmusson12 days
| | | | translation-miss tracing (the DtoH copy operand is the failing side)
* sema-svc: targeted 256-byte op + compute-channel release-block tracing (the ↵Arthur Hanson Rasmusson12 days
| | | | DtoH op is still invisible)
* sema-svc: log the LAUNCH_DMA push VA and injected/allow flags; widen the ↵Arthur Hanson Rasmusson12 days
| | | | op-failure log budget (the DtoH work path is invisible at the old caps)
* docs: retire the 2026-09-21 STATE.md snapshotArthur Hanson Rasmusson12 days
| | | | | | | - remove the superseded flat state page; current state lives in STATE-CURRENT.md and the docs tree - update the historical-material note in docs/README and the STATE-CURRENT header/see-also references
* guest-diag: retry the guest pin-scanner startup (a transient agent exec ↵Arthur Hanson Rasmusson12 days
| | | | failure left a boot without pins and the client hung)
* STATE-CURRENT: runtime bring-up started; runtime buffer translations are the ↵Arthur Hanson Rasmusson12 days
| | | | | | | | | wall - harness runs nvidia-smi and a static-runtime vectorAdd-style client - page-table walk succeeds at scale; larger runtime buffers still fail translation (host copies report missing entries) - frontier/active-work notes updated
* guest-diag: mount tracefs before installing kprobesArthur Hanson Rasmusson12 days
| | | | | | A fresh boot can leave /sys/kernel/tracing as an unmounted mount point; the probe adds then fail silently (probe count 0) and the whole sem/kptr pipeline goes blind.
* guest-diag: reset per-client pin state when a new client pid appearsArthur Hanson Rasmusson12 days
| | | | | | | A new CUDA client allocates fresh channel pools at the same GPU VAs; the watcher kept the previous client's sem kptrs and seen-pin marks, so it pinned the previous (freed) pool pages and the new client's release writes went to dead memory. Clear the learned sems/marks on each pid change.
* guest-diag: pin scanner matches va* clients too (static-cudart vectorAdd)Arthur Hanson Rasmusson12 days
|
* sema-svc: apply UVM increment releases once per GPFIFO slotArthur Hanson Rasmusson12 days
| | | | | | | | | | | UVM CE tracking semaphores start at a base value and each completed push adds the release payload (observed base 1 + payload 1 -> the client waits for 2). The absolute comparison (payload > cur) could not see the second push and the release was silently dropped, leaving cuInit/UVM stuck. Track applied GPFIFO slots in a per-channel bitmap (preserved across re-registration and the pump's snapshot write-back) so a pin-batch rewind replays entries without double-incrementing; rescued pages stay release-only and never mark a slot.
* guest-diag: cycle monitor CPUs on kernel-VA translation failureArthur Hanson Rasmusson12 days
| | | | | | | | | HMP x/gva2gpa translate with the selected vCPU's CR3; while that CPU runs user code under PTI the kernel half is hidden, so kernel-VA reads (the tracking-sem chain and the CE pushbuffer CPU alias) fail and the pin pass aborts. Try the other vCPUs before giving up: during an active CUDA client at least one CPU is in kernel mode, so the chain/pin work no longer require the client to be parked in sleep().
* STATE-CURRENT: full driver-API smoke test passes with payload 64/64Arthur Hanson Rasmusson12 days
| | | | | | | - milestone: cuCtxCreate through cuCtxDestroy with correct data roundtrip - GMMU walk decode fixed (real entry encoding); DtoH copy-engine-on-compute allowed for trusted injected pushes - ladder/diagrams/rails updated; next rung is real CUDA workloads
* sema-svc: execute CE-class work on host-injected compute pushes (the DtoH copy)Arthur Hanson Rasmusson12 days
| | | | | | | | cuMemcpyDtoH submits the copy as C5B5 methods bound on subchannel 0 of a compute channel (eng=0). allow_ops was false for every eng=0 channel, so the LAUNCH_DMA copy was decoded (and its release applied) but never executed, and the client read zeros. A host-injected translation is verified truth: allow CE work on those pushes too.
* guest-diag: cdt2 mapping scan is opt-in (CDT_SCAN=1); it can wedge the clientArthur Hanson Rasmusson12 days
|
* sema-svc: GRCE write log budget follows sema_ops_log when raised (catch late ↵Arthur Hanson Rasmusson12 days
| | | | HtoD writes)
* guest-diag: cdt2 payload scan limited to anon mappings (device-mapping reads ↵Arthur Hanson Rasmusson12 days
| | | | can block)
* guest-diag: cdt2 payload scan only touches anon/device mappings (avoid ↵Arthur Hanson Rasmusson12 days
| | | | SIGBUS on truncated file maps)
* guest-diag: cdt2 scans its own mappings for the payload after HtoD (DtoH ↵Arthur Hanson Rasmusson12 days
| | | | mechanism probe)
* sema-svc: CE op translation falls back to the GMMU walk for virtual operandsArthur Hanson Rasmusson12 days
|
* sema-svc: decode GMMU PDE/PTE addresses with the real encoding (addr>>12 in ↵Arthur Hanson Rasmusson12 days
| | | | | | | | | | bits 32:8/53:8) The mask-and-keep decode dropped the left shift by 12, so every page-table child pointer and leaf resolved 16x too low and no GMMU walk ever produced a translation (walks_ok=0 on every boot). Verified against live page tables: directory entry 0x2020a -> table 0x202000, leaf 0x0600000000760001 (aperture VID, KIND=6) -> PA 0x7600000.
* STATE-CURRENT: payload path found (compute-class inline DMA); page-table ↵Arthur Hanson Rasmusson12 days
| | | | | | | | | walk is the wall - smoke test ends ALL OK; data roundtrip pending the GPU-VA walk - HtoD identified as a GRCE inline-data DMA and decoded; destination translation is the remaining blocker - frontier/rail refreshed
* sema-svc: destination-keyed copy watch (dump page-table writes)Arthur Hanson Rasmusson12 days
| | | | | | sema_copy_dst=dumps the source bytes of every copy whose destination falls in the given page, so the 32-byte page-directory updates the guest writes into vidmem can be read directly and their entry encoding learned.
* guest-diag: pin scanner matches cdt* so the copy-path test binary is trackedArthur Hanson Rasmusson12 days
| | | | | | | The GR-window pin scanner matched comm=="cdt" exactly, so runs using the cuda_drv_test2 binary (comm "cdt2") never streamed their mappings: the GR push pages stayed unresolvable and the client stalled in context creation. Match the cdt prefix instead.
* sema-svc: decode GRCE inline-data DMA (small HtoD path)Arthur Hanson Rasmusson12 days
| | | | | | | | | | | | | | | | | | The 256-byte cuMemcpyHtoD payload never appears in any CE push: CUDA submits it on the compute channel as a compute-class DMA whose source is the push's own inline data (LINE_LENGTH_IN=256, OFFSET_OUT=<device VA>, LAUNCH_DMA=0x41, LOAD_INLINE_DATA 64 dwords, then the channel's SET_REPORT_SEMAPHORE release). The CE-shaped decoder skipped the data run (opcode 3) and no GR work ran at all. - Decode NVC5C0 GRCE methods on subchannel 1 (LINE_LENGTH_IN, LINE_COUNT, OFFSET_OUT/UPPER, LAUNCH_DMA) and the opcode-3 LOAD_INLINE_DATA run. - svc_grce_inline_write resolves the destination VA through trusted sources (pins, map, published page directories, targeted rm_mem resolve), pins the page and writes into vidmem or guest RAM; budgeted sema-grce logs name the target or report UNRESOLVED. - cdt2 test binary gains CDT_CP_PAUSE / CDT_HP_PAUSE for live inspection of the copy path; pushed by push_guest_tools.sh.
* sema-svc: run CE work before its release, grace unreadable CE entries, ↵Arthur Hanson Rasmusson12 days
| | | | | | | | | | | | | | | | | | | payload-pattern audit - CE LAUNCH_DMA releases are now applied after the push's collected work runs: the client reads copied data as soon as it observes the release, so release-first let cuMemcpyDtoH observe a copy that had not executed. - Unreadable CE entries stay pending for a grace window (sema_ce_grace_ms, default 8s) before the release fallback consumes them, so a translation that lands within a service pass lets the push be decoded and its work executed instead of being dropped. - sema_copy_pat matches an 8-byte value against every copy's src/dst first word and scans decoded pushes for it, naming the submission that carries a known payload regardless of size/encoding. - sema-dma-skip logs transfer-shaped launches that collect no op; op log lines carry the channel handle; LAUNCH_DMA inventory follows OPS_LOG. - A real release application now records the release VA, so decoded pushes no longer trigger a spurious fake release.
* guest-diag: cdt CDT_WAIT park-at-end (live memory inspection); run_cycle ↵Arthur Hanson Rasmusson12 days
| | | | CDT_WAIT passthrough
* sema-svc: copy-watch also logs dst8_after (write-effect check)Arthur Hanson Rasmusson12 days
|
* sema-svc: sema_vidmem_find pattern search (CE data-path ground truth)Arthur Hanson Rasmusson12 days
|
* guest-diag: pushbuffer pin survives PTI holes (full-range scan + bounded ↵Arthur Hanson Rasmusson12 days
| | | | retries until complete)
* sema-svc: sema_copy_watch (size-keyed src/dst byte audit for the CE data path)Arthur Hanson Rasmusson12 days
|
generated by cgit v1.2.3 (git 2.39.1) at 2026-10-12 16:27:59 +0000