summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAge
...
* vgsp: guest GR forwarding backend and capture (gsp_phys_gr_forward, default off)Arthur Hanson Rasmusson7 days
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add a default-off guest GR (compute) forwarding path so a guest CUDA launch submitted on its GR channel can be executed by the physical GR engine on the ladder channel, with fail-closed fallback to the host CUDA bridge and the unchanged software release path. - New module parameter gsp_phys_gr_forward (default 0) and accessor. - New GR execution gate: boot_stage.rmcall_gr_exec_ok, latched only after a real GR submission logs REAL GR SEM OK; the backend refuses while it is unset. - Sema capture: a completed 64-word inline QMD on a trusted, non-replay GR decode becomes an svc_gr_cand (push identity, decoded release0, parameter/program/pointer fields, up to 8 captured inline-write records); the CUDA bridge stays authoritative while the parameter is off and is reached in order forward -> bridge -> software release. - Backend: gsp_phys_backend_guest_gr_submit() maps pages at their own guest VAs through fresh Tier-1 small-PT pages/PDE installs or relocates inline-captured pages to ladder shadow pages (Tier 2), builds SET_OBJECT + the inline-QMD method run + REPORT_SEMAPHORE on the compute subchannel, reuses the shared GPFIFO/USERD/doorbell publish tail (extracted from the CE submit path, CE bytes unchanged) and polls the QMD release and/or module semaphore, draining the epoch-gated fault queue on timeout. - Sema wiring: GR requests reuse the INFLIGHT/hold/deferral machinery so the guest channel release applies only on the submit's success/failure edge; hold shims preserve the channel engine type. - Counters and a work_gr state line plus a stats accessor. - Bounds are fixed: 16 pages, 8 inline records, 64 QMD words; every pointer/size checked, pool exhaustion and stale mappings fail closed. - New ABI layouts pinned with static_asserts. Compile-only change: no device test performed. (cherry picked from commit ae507e6f241c7e3498728f9d1ffc2d41ede5cd64)
* vgsp: add gsp_phys_rmcall_channel to force one GR channel variantArthur Hanson Rasmusson7 days
| | | | | | | | | | Lets a bisection pair any promote shape with any channel shape, in particular V6 (SKIP_CTXBUFFER_ALLOC, KMD-managed) with the server-managed VA-only promote: with skip-ctxbuffer the server's kgrctxMapCtxBuffers does not pre-book the engine context vaList, so the VA branch's vaListSetManaged(NV_FALSE) gate should pass and the per-buffer commit can program the engine context VA. Default 0 keeps the mode-selected walk byte-identical. Not hardware-tested (GPU wedged; see Handoff ADDENDUM 51).
* vgsp: GR server-managed context commit experiments (EVICT, VA promote, ↵Arthur Hanson Rasmusson7 days
| | | | | | | | | | | | | | | | | | | | | | | | | external path) Rung-2 bisection after the GET_CTX_BUFFER_INFO ABI fix made the server ctx geometry visible (8 buffers; MAIN 0x133000 FBMEM, PATCH 0x5000): - map the server MAIN/PATCH at the ladder ctx VAs with FBMEM PTEs and send the UVM-shape VA-only promote (bInitialize=0, bNonmapped=0). On the shared VAS the per-entry VA branch calls vaListSetManaged(NV_FALSE) and returns 0x40 because the server pre-booked MAIN as managed; EVICT_CTX (status 0) does not release that booking. - try the same VA promote on the external VAS where the server did not book (kgrctxMapCtxBuffers early-returns): the promote never replies (-110) and leaves the device in the locked fail-safe (WPR2 up, unbound). Do not repeat this shape without a new hypothesis. - FBMEM physAttr selection for the server MAIN fixed (aperture 2 -> 0x4); gsp_phys_rmcall_srv_ctxcommit parameter added (0 = pure server-managed, no client promote). - query prints all 16 entries and records PATCH; query ABI 80-B/5136. Hardware state after the external-VAS run: GPU wedged, reboot required (no automated reboot). All shapes stay default-off behind gr_promote=17 + gsp_phys_srv_ctxbuf.
* vgsp: GR ctx query ABI fix, server-managed ctx map exclusion, raw diag captureArthur Hanson Rasmusson7 days
| | | | | | | | | | | | | | | | - NV2080_CTRL_GR_CTX_BUFFER_INFO is 80 bytes (NvBool is NvU8: flags at 56..59, uuid at 60) and the params are 5136 bytes, not 5648; the previous ABI mismatch is why GR_GET_CTX_BUFFER_INFO returned NV_ERR_INVALID_ARGUMENT (0x1f) on every shared-VAS cycle. - Under gsp_phys_srv_ctxbuf the GSP-RM server allocates/maps/commits the engine context itself: do not install the client GR context-window PDEs and do not map the client ctx VA in the PDB, so a client mapping cannot clobber the server's own context-window page table. - Dump the server-written INSTANCE/RAMFC chunks after BIND/SCHEDULE on the shared GR path so the committed engine-context pointer/VA can be located. - Emit the full NOCAT diag buffer as 16-byte hex rows (the printable copy is capped at 192 dotted bytes and hides binary fault dumps). Untested on hardware at commit time; the next supervised GR cycle validates.
* vgsp: fix per-type VRAM type lookup and canonical FB-size encodingArthur Hanson Rasmusson7 days
| | | | | | | | | | | | | | | | | The 708a3802 per-type VRAM change stripped an nvidia- prefix from mdev->type->sysfs_name, but sysfs_name is the registered type name verbatim; the mdev core only prefixes the type DIRECTORY with the parent driver string. Every lookup failed, so all mdevs silently fell back to 512 MiB, nvidia-vgpu-turing-1g was unreachable and available_instances capped at 1. Match sysfs_name directly in get_available, show_description and mdev_create. Also canonicalise the NV_PFB_PRI_MMU_LOCAL_MEMORY_RANGE encoder (BAR0+0x100ce0) by stripping factors of two from MAG so 512 MiB encodes 0x19 again (1 GiB 0x1a, 2 GiB 0x1b) instead of the non-canonical 0x204. Default-512M behaviour is now byte-equivalent to the known-good pre-VRAM module except max_instances=2. Module sha256 cb1724d3.
* vgsp: per-mdev emulated VRAM size (1.0 multiple mediate sizes)Arthur Hanson Rasmusson7 days
| | | | | | | | | | | | - nv_vgpu_type_info/ioctl gain vram_mb; nv_vgpu_device gains fb_emul_size bound from the mdev type at create (default 512 MiB). - New nvidia-vgpu-turing-1g type (1024 MiB); turing max_instances 1 -> 2; show_description reports the per-type framebuffer and max_instance. - Thread fb_emul_size through GSCI fb_length/region/frtsOffset, WPR2, NV_PFB_PRI_MMU_LOCAL_MEMORY_RANGE, the vidmem allocator bound and the BAR1 shadow; bar_info callback uses the per-device size. - UNTESTED at commit time: builds clean; validation blocked by the Xid 140 incident (reboot pending). See Handoff-vGPU-IO.md ADDENDUM 48.
* vgsp: GR shared path ctx-window PDE install and PATCH+MAIN PA-only promote ↵Arthur Hanson Rasmusson7 days
| | | | | | | | | | | fallback - UPDATE_PDE_2 now also installs the GR context window PT pages (PDE 17+). - The shared-path fallback promotes PATCH then MAIN PA-only (mode-13 order, the real client's set); the mapped (bNonmapped=0) entry still hits the known 0x40 structural gate and is not sent. - Shared+srvctx: channel/BIND/schedule/token/GPFIFO fetch all green; the remaining failure is ROBUST_CHANNEL_GR_FAULT_DURING_CTXSW (0x2c).
* STATE-CURRENT: 12:16 check-back snapshot (GR stage-4 frontier: PBDMA fetches ↵Arthur Hanson Rasmusson7 days
| | | | GPGet=1, ctxsw fault 0x2c; 10 clean no-wedge cycles; GR fixes committed)
* vgsp: GR ladder shared-VAS page-table install and server-managed ctx commit pathArthur Hanson Rasmusson7 days
| | | | | | | | | | | | | | | | - DMA_UPDATE_PDE_2 client control installs the ladder leaf PT through the server's own MMU walker on the shared-management VAS (the raw-PDB entries are not preserved by the root migration); FLUSH_PDE_CACHE + post-install refill + PT diagnostics. - srvctx registry profile also disables split VAS management; MAP_MEMORY_DMA is not served by GSP-RM for this client (NV_ERR_INVALID_FUNCTION), so the PDE control replaces it. - shared-path context commit helper: GPU_INITIALIZE_CTX + PA-only GPU_PROMOTE_CTX for the server-reported (or client fallback) MAIN buffer; GR_GET_CTX_BUFFER_INFO sends bufferCount=64. - Result: shared VAS + srvctx no longer wedges; channel/BIND/schedule/token green, PBDMA fetches the GPFIFO (GPGet=1); remaining wall is ROBUST_CHANNEL_GR_FAULT_DURING_CTXSW (0x2c).
* STATE-CURRENT: hourly check-back snapshot (2026-10-05 12:12:01)Arthur Hanson Rasmusson7 days
|
* STATE-CURRENT: 10:38 check-back snapshot (campaign 239-242 green; 243b live; ↵Arthur Hanson Rasmusson7 days
| | | | committed experiment e7ff3bf7)
* STATE-CURRENT: 10:12 check-back snapshot (hold-all-unreadable experiment ↵Arthur Hanson Rasmusson7 days
| | | | committed, module e7ff3bf7, campaign 239-262 validating)
* STATE-CURRENT: 06:50 check-back snapshot + debugging-options catalogueArthur Hanson Rasmusson7 days
| | | | Refresh the status page: the acceptance is holding under hardening (per-op once bitmap, epoch/content-hash gate, 15 s CE grace; first-attempt 86% -> ~94-95%, fakes/run 3.39 -> 0.61), the hold-all-unreadable experiment is live, and the residual classes are named (late-decode corruption, early UVM channel-manager stall, guest init panic). Add an options section listing candidate techniques that would accelerate debugging toward end-to-end CUDA (deterministic fault injection, offline pump model, structured host tracing, guest-memory forensics, GR-wall metadata/golden reference/static-analysis throughput, cheaper supervised cycles, concurrency checks, tooling automation) - explicitly not directives, each requiring an eng-ops admission record.
* vgsp: hold every unreadable CE entry for the grace; delete the silent ↵Arthur Hanson Rasmusson7 days
| | | | | | | | | | pre-rescue fake An unreadable CE entry whose channel already had a decoded release VA was faked immediately and consumed with no log line, before any rescue attempt. A later pin-batch rewind then executed the skipped copy against a staging buffer the client had since refilled - the deterministic vadd input shift seen in runs 94/122/151/173b/215b, each with a silent pre-rescue fake. Now every unreadable CE entry with an expected payload is held for the bounded grace and the rescue is retried on each pass, so a translation that is still coming wins and the work runs before the release. Only an entry whose release was already delivered (the channel moved past entry_want) is consumed at once; the post-rescue fake remains the bounded, visible escape. The CE grace default moves 15000 -> 25000 ms (a translation arrived ~17 s after first examination in 215b). Under live campaign 229-236 (module 97eba5b7; green so far).
* docs: record GR promote-wall static findings (handler/commit map, ↵Arthur Hanson Rasmusson7 days
| | | | external-VAS vaList gate, rec-677)
* vgsp: widen the CE pending-entry grace to 15 sArthur Hanson Rasmusson7 days
| | | | | | | | | | | A consumed entry's work is never run; if its release lands via the fallback before the entry's copies have executed, the client refills the staging slot the copies then read (observed as the deterministic one-chunk vadd input shift). Keep untranslatable CE entries pending longer so their copies run before any release reaches the client. 8-cycle pilot (141-148): zero corruption; a red-fingerprint cycle (held=1165, ring_auto=6) healed to ring_auto=26 with faked=0 and the exact checksum, where the 8 s window recorded 1 corruption in 36.
* vgsp: never run work for a slot consumed without it (epoch mark + ↵Arthur Hanson Rasmusson7 days
| | | | | | | | | | | | | | | | | | | | | | | | | | | | content-hash once gate) The grace-expiry fake path consumed a held CE entry without marking its GPFIFO slot as consumed for the put epoch, and the replay guard only ran while the channel was not deferring. A later pin-batch rewind then re-read the slot, found no recorded identity, and executed the push's copies against a staging buffer the client had refilled after the faked release - a deterministic vadd input shift (a[k] == h_a[k + 2 MB]). - grace-fake consume path now calls svc_replay_note() before advancing; - the svc_replay_seen() replay skip is evaluated unconditionally: a slot consumed in the current epoch is skipped on every replay, deferral or not, until a put wrap clears the mark; - the once-only identity gate gains a content witness (FNV-1a hash of the recorded push bytes): the same entry words with different push content is a new push (clients rewrite push buffers in place) and runs its ops with a cleared done bitmap; suppression requires identical content; - snapshot write-back persists the hash array; new drain counter reident= counts content-mismatch cancellations; - the grace window stays at 8 s: a faked entry's work is never run, so the hold is that work's only chance (a 2.5 s experiment made red-class runs complete with corrupt data instead of timing out). Verified: module 8e90fc7e..., three consecutive end-to-end acceptance runs (MAIL + VADD bad=0 checksum=392344090.500000 + STATUS OK).
* docs: note live verification of the per-op once gateArthur Hanson Rasmusson7 days
| | | | | | A later supervised cycle reproduced the held-entry retry over a refilled staging buffer, the completed operation was skipped, and the end-to-end transfer verified byte-for-byte (bad=0, expected checksum).
* vgsp: once-only op execution per entry identity, per-op done bitmapArthur Hanson Rasmusson7 days
| | | | | | | | | | | | | | | | | | | | | | | | | The pump's operand-targeted-scan hold decodes a push, runs every op that translates, then leaves the entry pending for a retry. The retry re-decoded the whole push and re-ran the operations that had already completed. A CE copy reads a client staging buffer the client refills per chunk, so the retry overwrote a finished chunk with the following chunk's data (observed: the bridge's vadd input half replaced by the next 1 MB chunk, first half of the device buffer byte-identical to the source shifted by exactly 2 MB; the same 1 MB copy logged twice with different staging contents). The service now records, per GPFIFO slot, the entry identity plus a bitmap of the decoded operation indexes whose work has executed for that identity, and a complete flag for a pass that ended with no operand pending. svc_run_ops skips already-executed ops on a retry and marks the rest as they succeed; the pump stores the record immediately after decode, before any hold path can break, so the pending path can no longer lose it. A replay of a complete identity suppresses all ops; a partial identity retries only what is owed. Also carries the ops_once diagnostic counter in the service snapshot line and documents the operation-granularity rule in the architecture doc.
* greeneye: GMMU/FBIF observability, PTE decoder and oracle, MPU/libos ↵Arthur Hanson Rasmusson7 days
| | | | | | simulator wave Simulator development wave (docs 42-44): GMMU page-table entry decode with its oracle/workflow harness, FBIF observability, and MPU/LIBOS device surfaces in the device model, plus refreshed boot/machine/profile data (tu104-570.144), the qemu-line results, and the new unit tests. Docs 00/06/35-41 updated to match; harness helpers and .gitignore included.
* vgsp: per-op once-only execution bitmap for retried GPFIFO entriesArthur Hanson Rasmusson7 days
| | | | | | The entry-identity gate suppresses every operation on a replayed entry, but an entry held because one operand's targeted scan was still running is decoded again on retry, and the ops that already succeeded would re-run against a staging buffer the client has since refilled (observed: a retried HtoD wrote the second vadd input half into the first). Track a per-slot bitmap of the operations (0..63) already executed for the slot's current entry identity, plus a complete flag for the pass that finished with no operand pending. On replay, a complete entry suppresses all ops; otherwise the bitmap decides per operation. Successful fills/copies set their bit, and the skipped count is published as ops_once in the drain line.
* STATE-CURRENT: 18:45 check-back snapshot (first green end-to-end guest CUDA ↵Arthur Hanson Rasmusson7 days
| | | | | | acceptance; 14/15 repeat cycles green) Refresh the public status page for the 2026-10-04 acceptance: noclaim38/39/40 report MAIL + VADD n=1048576 bad=0 checksum=392344090.500000 + STATUS OK with identical hashes (committed aa3520f2); the repeat campaign shows 14 of 15 green with the remaining failure the known intermittent guest-side flake. Update the milestone ladder (CUDA kernel execution now green via the no-claim host bridge; guest engine forwarding to the physical GPU still the open backend wall) and the milestone index/log.
* vgsp: end-to-end CUDA acceptance in the guestArthur Hanson Rasmusson7 days
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The no-claim emulation path now runs a stock CUDA program end to end: device properties, cudaMalloc, a GPU-authored string kernel read back byte-for-byte, two 4 MB host-to-device copies, a 1 M-element vectorAdd executed on the physical GPU through the host bridge, and the device-to-host copy-back verified element by element. Three consecutive supervised cycles report MAIL + VADD bad=0 checksum=392344090.500000 + STATUS OK with identical input/output hashes. Two data-path correctness fixes make the transfers sound: - Once-only op execution per GPFIFO entry. The pump replays recently consumed ring entries when translation batches are injected so missed releases can land; re-executing a CE copy is not idempotent because its source is a client staging buffer that may have been refilled. Slots now record their raw entry words and a replayed entry matching that identity suppresses operations while still processing releases. - Per-page translation of virtual operands. svc_copy resolved only the first page of a VA range and walked the PA linearly; client staging ranges are frequently split (observed 195 + 61 pages), so the tail of alternating chunks was read from unrelated memory. Multi-page copies now re-resolve each 4 KB page through the trusted resolver. Also carries the earlier uncommitted emulation fixes that got the client to the launch (QMD address-window gate, counter registration persistence, 512 MiB emulated FB, bridge slot hygiene) and bounded diagnostics (sema-bigop, sema-bigcopy, bridge-in/out hashes, daemon INCHECK/OUTCHECK/dumps).
* STATE-CURRENT: 15:12 check-back snapshot (no-claim bridge reaches guest ↵Arthur Hanson Rasmusson8 days
| | | | vectorAdd launch; mail read-back fixed; bridge slot oops + approved reboot; post-reboot run blocked by guest boot panic)
* STATE-CURRENT: 21:12 check-back snapshot (2026-10-03 victory wave, no-claim ↵Arthur Hanson Rasmusson8 days
| | | | Xid recovery, GPU-only VA->PA wall)
* vgsp: host CUDA bridge + sema release recovery; greeneye simulator waveArthur Hanson Rasmusson9 days
| | | | | | | | - kernel: gsp_cuda_bridge (QMD launch capture, debugfs job/out/done, param+output resolution cached from inline writes), sema drain fixes (never hold/starve a channel), GR ring autopin + counter autoreg, per-page push reads, counter-derive gate; module builds clean - tools/cuda-bridge: CUDA driver-API daemon executing mail/vadd kernels on the physical GPU, CUBB2/CBD2 v2 protocol, layout check + self-tests - tools/guest-diag + tools/cuda-ab: scanner/pin fixes, victory push-only mode - debug/risc-v-gsp-rm-vm: Phase S simulator wave (GSP device model, boot ladder, triage/re-demo harnesses, docs 30-41), GPGPU-sim scaffolding - STATE-CURRENT/docs updates
* STATE-CURRENT: 22:12 check-back snapshot (first real guest victory program ↵Arthur Hanson Rasmusson9 days
| | | | exercised against the physical backend; reaches device properties then stalls in UVM channel path)
* STATE-CURRENT: hourly check-back snapshot (2026-10-02 18:12:01)Arthur Hanson Rasmusson9 days
|
* STATE-CURRENT: 17:12 check-back snapshot (GR promote wall = externally-owned ↵Arthur Hanson Rasmusson9 days
| | | | VAS; shared-VAS opens 0xc5c0 object-alloc wedge; host in locked fail-safe pending reboot approval)
* STATE-CURRENT: 16:12 check-back snapshot (GR modes 18/19; mode-19 wedge ↵Arthur Hanson Rasmusson9 days
| | | | cleared by approved reboot; commit/RAMFC wall unchanged)
* kernel: capture the guest's PROMOTE_CTX entries; add promote mode 19 ↵Arthur Hanson Rasmusson9 days
| | | | | | | | | | | | | | | (guest-faithful 9-entry set) - gsp_rm_emulation: dump every guest GPU_PROMOTE_CTX (0x2080012b) params and entries so the real client's promote shape is observable (captured on the emulation path: MAIN 2 MB PA+VA, PATCH, BUNDLE_CB/PAGEPOOL/ATTRIBUTE_CB/ RTV_CB_GLOBAL VA-only, FECS, PRIV, UNRESTRICTED) - gsp_phys_booter: promote mode 19 replays that exact 9-entry shape on the V5 channel with host buffers (MAIN 2 MB + PDB map, small buffers, booking-only VAs); clamp 0..19 - docs/eng-ops: mode-19 result recorded - the server never replied (fn76 -110) and the release fail-safe held WPR2/GPU until an approved reboot; mode 19 is known-wedging
* kernel: GR promote mode 18 (client FERMI_CONTEXT_SHARE_A via hContextShare)Arthur Hanson Rasmusson10 days
| | | | | | | | | | | - gsp_phys_booter: mode 18 allocates a FERMI_CONTEXT_SHARE_A (0x9067) on the TSG with the ladder VAS and carries it as hContextShare on the V6 KMD channel, so the share construct can allocate the GraphicsSubcontext the single-MAIN promote needs; clamp 0..18 - docs/eng-ops: GR promote bisection row updated with the session-2 results (modes 12-18: PA-only accepted but no ENG_CTX_VALID; PATCH/PM/FBMEM and server-managed registry all leave the KMD promote at 0x40; wall is the commit/RAMFC path)
* STATE-CURRENT: 15:12 check-back snapshot (post-reboot GR campaign; ↵Arthur Hanson Rasmusson10 days
| | | | commit/RAMFC wall)
* kernel: GR context-promote bisection modes 4-17 and server-managed-ctxbuf ↵Arthur Hanson Rasmusson10 days
| | | | | | | | | | | | | | | | | | | | registry variant; complete vgsp rename; docs/tooling refresh - gsp_phys_booter: GR promote bisection modes 4-17 (two-phase zero-field VA, batched entries, hVirtMemory, bare VA, KMD SKIP_CTXBUFFER_ALLOC channel, old-interface GPU_INITIALIZE_CTX, FBMEM context buffer, UVM-faithful PA-only, PATCH/PM auxiliary promotes, server-managed no-promote path); PATCH/PM geometry queries and buffers; pre-boot SET_REGISTRY profile selection - gsp_phys_gpu: gsp_phys_rmcall_gr_promote clamp 0..17 and gsp_phys_srv_ctxbuf parameter; registry image variant with RMSetClientRMAllocatedCtxBuffer=0 - vgsp rename across kernel, scripts, tools and docs (module vgsp.ko, /sys/kernel/debug/vgsp/, vgsp-<subsystem>: log prefixes) - risc-v-gsp-rm-debugger user-facing rename and docs/CI refresh; guest-diag tool updates; README/SBOM/install/Makefile sync Live status: CE ladder and P6 guest-copy forwarding green; GR engine context commit still open (all promote shapes accepted or cleanly refused; the channel stays CTXNOTVALID) - see Handoff-vGPU-IO.md Addendum 21 (local).
* STATE-CURRENT: hourly check-back snapshot (2026-10-02 15:12:02)Arthur Hanson Rasmusson10 days
|
* STATE-CURRENT: hourly check-back snapshot (2026-10-02 14:12:01)Arthur Hanson Rasmusson10 days
|
* debug: risc-v-gsp-rm-debugger final pass - remove in-development notices, ↵Arthur Hanson Rasmusson10 days
| | | | | | | | | | | | complete rename, adversarial-review fixes Remove the '# TOOL IN DEVELOPMENT - NOT READY YET!' notices from the tool docs/README/scripts and the project docs; record the removal (2026-10-02) against the tool audit (debug/risc-v-gsp-rm-vm/docs/27-TOOL-AUDIT.md), the 194-test suite and the value-validation demos (docs/25-VALUE-VALIDATION.md). Complete the cosmetic rename to risc-v-gsp-rm-debugger in user-facing prose and commands (launcher, roadmap, docs); internal greeneye package and code identifiers unchanged. Adversarial-review fixes: deterministic control-discovery sweep (flaky test root-caused), UUID session dirs + atomic JSON writes for concurrent runs, Ghidra bridge loopback enforcement and clean shutdown, fp register restore in Session.call, version_diff --dry-run, 30 s interrupt budget, dry-run non-destructiveness verified. Docs: flag-removal records, link fixes, command/flag corrections (fdematch arity, port_new_device --out, trace filename), F2 orchestration note in future-eng-ops; STATE-CURRENT status refreshed.
* rename (cosmetic): green-eye -> risc-v-gsp-rm-debugger in user-facing names, ↵Arthur Hanson Rasmusson10 days
| | | | docs, CLI, launcher and CI workflow; internal greeneye package/module identifiers unchanged (includes in-flight greeneye module edits present in the tree)
* debug: green-eye porting automation - new-device and driver-version port ↵Arthur Hanson Rasmusson10 days
| | | | scripts, simulator packaging, porting docs; control-discovery fix
* gitignore: keep the local evidence workspace and generated demo artifacts ↵Arthur Hanson Rasmusson10 days
| | | | untracked; drop built RM tool binaries (source and Makefiles stay)
* docs: engineering-operations playbook and project-wide status accuracy passArthur Hanson Rasmusson10 days
| | | | | | | | | | | | | | | | | | | | | | | | - docs/eng-ops.md gains Part II, live physical-backend engineering operations: hard rules, the full module-parameter matrix, the routine supervised cycle and clean-release checklist, the debugfs inventory, how to read gsp-phys-state, a debugging scenario catalogue (CTXNOTVALID/promote wedge, fail-safe WPR2, unload hangs, guest wedges, MMU/PTE and PBDMA faults, relay symptoms), a hazard register (crash causes and debugging side effects), the physical-backend OODA loop, and the work-context map with porting flows - architecture, implementation, operations, orientation, getting-started, portability, ecosystem and reference docs corrected to the current state: CUDA driver-API smoke green, CE-class work forwarding and engine-authored releases plus fault relay in place (default off), GR execution blocked on engine-context validity, the promote wedge and designed locked fail-safe, and P5 wave-2 subsumed - internal-reference cleanup in tracked docs (no analysis-source or local-archive references); historical architecture document bannered - README reading list and STATE-CURRENT frontier refreshed; new pages (runbook, green-eye user guide, porting sequence, porting/packaging notes) linked from the tree Link check: scripts/check-docs-links.py passes (56 files, no broken links).
* debug: green-eye wave 3 - RM harness, local simulator, device map, MCP ↵Arthur Hanson Rasmusson10 days
| | | | plugin, value-validation demos, CI pipeline, toolchain docs; add host RM tools rmtool/rmtop
* gsp-phys: GR engine context allocate/map/promote before the GR sem push ↵Arthur Hanson Rasmusson10 days
| | | | (default off; live-unverified at promote)
* STATE-CURRENT: 10:55 check-back - H1 promote-ctx wedge, designed locked ↵Arthur Hanson Rasmusson10 days
| | | | fail-safe hold, green-eye wave 2
* debug: green-eye wave 2 - injection SDK, Frida-like calls, Ghidra control ↵Arthur Hanson Rasmusson10 days
| | | | | | | | | | | | | | | | | | | | | | | | | | | bridge, long-term docs Adds to debug/risc-v-gsp-rm-vm/: - Session.call / run_until: Frida-like remote function calls and run-to-cursor, with register restoration; verified live (rpc_ping -> 0xaffe). - symbol+offset target resolution (gsp_ctrl+0x10) across all APIs and the REPL. - Injection SDK (sdk/) and 'greeneye inject': position-independent RV64 service blobs (verified zero relocations), loaded into RAM, registered in the demo handler table, and invoked either directly or through the firmware mailbox dispatcher. Demo ABI extended: mailbox 16..23 selects slots, arg0 carries the service command, arg2 added (struct now 0x190; schema updated). - Ghidra control bridge (greeneye ghidra + GreenEyeControl.java): run-until-here, breakpoints, memory/register access, remote calls, hit export; verified end-to-end with Ghidra headless (run_until reached rpc_sum from a GhidraScript). - MarkGreenEyeHits.java fixed for the Ghidra 12 createBookmark API; verified headless together with ExportForGreenEye.java. - Analyzer renders a QEMU first-fault table for probe sessions (fault count, epc with firmware vaddr translation, access address/size, reason). - Tests now 35 green, including injection, Ghidra bridge, remote call, run-until and REPL command smoke tests. - Documentation: docs/11-16 (GSP RM service developer guide, injection SDK specification, Ghidra control, adversarial interoperability guide, agentic GSP IDE, custom simulator design) and GREEN-EYE-ROADMAP.md (long-term H1-H7 program); doc maps and the project RISC-V VM doc updated.
* STATE-CURRENT: 09:25 check-back - P6c relay (C0/C1/C3), H1 host GR ladder ↵Arthur Hanson Rasmusson10 days
| | | | wall, green-eye tooling
* gsp-phys: relay verify hardening and counter exposure (default off)Arthur Hanson Rasmusson10 days
| | | | | | | | | | | | | | - 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.
* debug: add green-eye GSP/uproc RISC-V VM runtime analysis toolingArthur Hanson Rasmusson10 days
| | | | | | | | | | Adds open-iov/debug/risc-v-gsp-rm-vm: a GDB-free instrumentation stack that boots uproc/GSP firmware in qemu-system-riscv64 and provides Frida-like hooks, breakpoints, watchpoints, memory dumps, structure decoding, snapshot diffs, recorded sessions, declarative probes, a plugin API and a Ghidra symbol/hit bridge. Verified: 25 tests green (including a live QEMU smoke test); the demo uproc boots with correct hook/leave/watch/schema/snapshot/fault evidence; the optional TCG trace plugin builds and recorded 15M trace lines in 3 s; the TU104 570.144 fwimage probe reports its first exception (load access fault at firmware vaddr 0x4009014 reading 0x2000000000000A00). Documentation: lean tool docs under debug/risc-v-gsp-rm-vm/docs/00-10, a new docs/05-operations/03-risc-v-gsp-rm-vm.md debugging document, and '# TOOL IN DEVELOPMENT - NOT READY YET!' markers in docs/README.md, the onboarding tooling table and the debugging workflows doc. Vendors qemu-plugin.h from QEMU v8.2.2 (GPL-2.0-or-later), with its license header intact, so the optional TCG plugin builds without a QEMU source tree.
* gsp-phys: H1 GR ladder - GR0 channel, compute object, GR sem push (default off)Arthur Hanson Rasmusson10 days
| | | | | | | | | | | | | | | | | | | | | | | New load-time gsp_phys_rmcall_engine (0=COPY0 default, 1=GR0) parameterizes the physical ladder: TSG and channel engine_type GR0, one-attempt channel alloc, TURING_COMPUTE_A engine object (class 0xc5c0, handle 0xcaf0002c), BIND engineType=1, and a GR method push (SET_OBJECT 0xc5c0 on subchannel 1 plus SET_REPORT_SEMAPHORE) submitted through the existing GPFIFO/USERD doorbell tail, polling the module semaphore. CE work-forwarding refuses cleanly while a GR ladder is active. A debugfs trigger re-runs the GR push. With the parameter at its default the ladder emits byte-identical COPY0 requests (only the state line gains engine=COPY0). Live (first GR context on the live server): every GR RPC accepted - channel variant V5, TURING_COMPUTE_A alloc status=0x0 -> hObject=0xcaf0002c, BIND status=0x0, token=0x1 - and the engine fetched the push (GPGet 0->1), but raised a GR exception instead of executing the release: exceptType=0x20, NOCAT faultingEngine="GR", intr1=0x80000000, no rpc_result errors. The failure is downstream of all RPCs; no mutating retry was made and the device released cleanly (WPR2 down, rebound, 5 locks, pstore empty, same boot). A default-engine control cycle stayed green (REAL COPY OK). Follow-up: bisect the GR alloc params, the release method D word, and the method order/context init using the drained GR fault records as the oracle.
* gsp-phys: P6c C3 - relay forwarded-engine faults to the guest (default off)Arthur Hanson Rasmusson10 days
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-10-12 07:36:49 +0000