summaryrefslogtreecommitdiffstats
path: root/docs
Commit message (Collapse)AuthorAge
* docs: record GR rung-2 ctx-query ABI fix and the managed-booking wallArthur Hanson Rasmusson7 days
| | | | | | | | | | Document the corrected GR context-buffer query ABI (80-byte entries, 5136 byte params), the new gsp_phys_rmcall_srv_ctxcommit / gsp_phys_rmcall_channel / gsp_phys_gr_forward parameters, and the live 2026-10-05 findings: PA-only never commits the engine context pointer; on the shared VAS the server pre-books MAIN as managed so a client VA-only promote returns 0x40 at the vaListSetManaged gate; EVICT_CTX does not release it; the external-VAS VA-promote shape wedged the device and must not be repeated.
* 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 Rasmusson8 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 Rasmusson8 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.
* vgsp: end-to-end CUDA acceptance in the guestArthur Hanson Rasmusson8 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).
* 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
* kernel: capture the guest's PROMOTE_CTX entries; add promote mode 19 ↵Arthur Hanson Rasmusson10 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)
* 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).
* 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)
* 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
* 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.
* 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: P6b waves 1.5 and 2 - deferred release and hardware-authored guest ↵Arthur Hanson Rasmusson10 days
| | | | | | | | | | | | | | | | | | | | | | | | copies - new default-off gsp_phys_work_defer_release: a forwarded guest push's releases are recorded and its GPFIFO entry is held (no consume, no GP_GET write, no counter publish/stall) until the work item publishes completion; the service thread then delivers the releases, with a fallback on failure/timeout (500 ms cap enforced every pump pass)/ pause/quiesce/channel-delete - new default-off gsp_phys_work_hw_primary: the software copy is skipped for forwarded ops, so the physical engine authors the data; a once-only software copy runs before the releases on any hardware failure or when the request cannot be queued - release-apply helpers extracted; exactly-once latches; channel-delete and teardown handling; counters and a work_guard state line - live: deferred-release run engaged=75 applied=75 timeouts=0 with the full smoke green; hardware-primary run req=100 ok=100 verify_ok=100 fallback=0 copy_skipped=119 copy_fail=0, smoke ALL OK 64/64 (guest read data the engine authored), with 19 fail-closed inline software fallbacks under single-inflight contention; a range-unregistered run proved the fallback (121 skipped copies, all recovered, smoke green) - defaults off; the software path and all existing guards unchanged
* gsp-phys: P6b wave 1 - shadow-forward guest CE copies to the physical engineArthur Hanson Rasmusson10 days
| | | | | | | | | | | | | | | | | | | - the sema service captures the first eligible copy per push from the software resolver's own operands (the real push shape mixes guest RAM with emulated-VRAM shadow addresses, including physical destinations) - HPA resolution: guest RAM through the shared guest-RAM file page cache, emulated VRAM through the mapping of its kernel shadow - new scratch page-table pool: 16 zeroed page-table pages with their page-directory entries built before any engine access, handing out one whole 128-byte GMMU PTE fetch line per copy pair (16 PTEs, 512 pairs per boot, never reused; a PTE written into an already-fetched line is not observed and there is no invalidate path) - the backend submits the copy on the module-owned channel and verifies the result host-side; every miss falls back to the ladder shadow copy, and the software pump remains authoritative - live (full smoke, both parameters on): req=42 ok=42 verify_ok=42 verify_fail=0 fallback=0, guest payload roundtrip ALL OK 64/64, clean latched release; defaults stay off
* gsp-phys: P6a - real copy engine reads/writes guest RAM pagesArthur Hanson Rasmusson10 days
| | | | | | | | | | | | | | | | | | | - file-backed guest RAM (launcher memory-backend-file share=on) and in-kernel GPA->HPA translation through the shared file page cache (read_cache_page + page_to_phys + pfn_valid), opened O_LARGEFILE; new default-off gsp_phys_guest_mem parameter - debugfs gsp-phys-guest-ram (path + gpa/off/size ranges) and gsp-phys-guest-gpa (one pinned GPA per boot); rm-call triggers 6/7 run host->guest and guest->host 4 KiB CE copies; trigger 8 is a PTE self-test through a fresh slot - guest page-table slots are pre-built during ladder stage 3: runtime PTE writes into an already-walked page-table line are not observed without a TLB invalidate - guest RAM layout (q35 4.2, 4 GiB): below-4G GPA == file offset, above-4G offset = GPA - 0x80000000 (2 GiB PCI hole) - tests: tools/test/gpage_test.c guest probe; docs + STATE-CURRENT record the live green (G2H/W2G with semaphore release, guest observed the write, smoke ALL OK 64/64, clean latched release)
* docs: add complete SBOM, ignore local deployment resources, remove stale ↵Arthur Hanson Rasmusson10 days
| | | | third-party references
* STATE-CURRENT + docs: record P2 identity overlay, P3 control forwarding and ↵Arthur Hanson Rasmusson10 days
| | | | P5 wave-1 shadow execution
* STATE-CURRENT + docs: record the freeze fix and the P2/P3 guest-wiring landingsArthur Hanson Rasmusson10 days
| | | | | | | | - STATE-CURRENT snapshot moves to the P3 frontier: the host-freeze latch and readiness gates are validated, the static identity overlay and the read-only control forwarding are landed and live-verified - the physical-backend guest-wiring design is now marked P0-P3 implemented with the P2/P3 acceptance results
* docs: gate post-1.0 host acceleration as do-not-implementArthur Hanson Rasmusson10 days
| | | | | | | | | | Clarify in the post-1.0 record and the public status page that host-native acceleration / host display is a stretch goal we are only considering: do not block on it, pursue it, or design around it. It is never reached automatically, requires an explicit human decision after all baseline goals are complete (and only once there is no known risk), and may be scrapped on architectural grounds. No aspect of the baseline software may be designed toward it. No baseline design or code changes.
* docs: defer experimental host acceleration to post-1.0; record rationaleArthur Hanson Rasmusson10 days
| | | | | | | | | | | | | | | | | The host-VF design is reverted. Independent adversarial, soundness and VM-support reviews falsified its load-bearing mechanisms: RAM-backed BARs cannot be ioremapped or claimed by the stock driver on x86_64 or aarch64; trap-free windows cannot observe edge-triggered writes or read side effects; multi-client GSP-RM is unproven; the MSI and bridge bring-up plans were incorrect; and the isolation and performance claims were overstated for the mechanism. Replace it with one self-contained post-1.0 document recording the findings, corrected candidate approaches and trade-offs, a minimal-risk future architecture, the compile-time + module-load experimental gating policy, a phased plan with abort gates, and the revisit criteria. No baseline design or code path is changed; all earlier doc edits are reverted.
* docs: record host VF acceleration as a deferred future goalArthur Hanson Rasmusson10 days
|
* STATE-CURRENT + docs: first real copy executed by the physical CE; add the ↵Arthur Hanson Rasmusson10 days
| | | | | | | | | | | | | | physical-backend guest-wiring design - STATE-CURRENT snapshot 2026-10-01 21:05: the host RM-client ladder now allocates VAS+PDB+TSG+channel and executes a real 4 KiB VA-mode CE copy (semaphore released, dst==src) on the physical engine; next is wiring the live session into the guest-facing mdev/vfio path. - docs/03-architecture/11-physical-backend-guest-wiring.md: phased design (P0-P6) for bridging the physical backend into the guest-facing emulation, with the seam table, lifecycle changes and static-config flow. - docs/README.md: reading order updated for the new document; execution status refreshed.
* gsp-phys: populate the chipset/CL block of the pre-boot system infoArthur Hanson Rasmusson11 days
| | | | | | | | | | | | | | | | | | | | | | Fill the GspSystemInfo chipset fields the production client syncs before the GSP boot instead of leaving them zero: - clPdbProperties (bitmask in the client's clSyncWithGsp order): bit 0 (config space accessible, from the OS MCFG/ECAM availability), bit 7 and bit 21 (Intel Skylake-family upstream-port setup: ASPM POR list, root-port nosnoop WAR), bit 13 (upstream port ASPM L1 capable), bit 27 (LTR supported+enabled up to the root port) and bit 32 (IO coherent). PDB_PROP_CL_UNSUPPORTED_CHIPSET is never assigned by the client, so the faithful unmatched-chipset value is 0. - Chipset = 0 (CS_UNKNOWN) for a host bridge with no chipsetInfo[] entry, the reference's no-match fallback. - FHBBusInfo/chipsetIDInfo: 10-byte BUSINFO blobs of the first host bridge of the GPU's domain (device, vendor, subdevice, subvendor, revision), with the subsystem-capability fallback on chipsetIDInfo. acpiMethodData is intentionally sent all-zero (bValid=0): no ACPI/AML calls are made and every consumer tolerates the no-data encoding. All device lookups use refcounted pci_get_device()/pci_dev_put().
* gsp-phys: queue the pre-boot GSP_SET_SYSTEM_INFO and SET_REGISTRY async RPCsArthur Hanson Rasmusson11 days
| | | | | | | | | | | | | | | | | | | The real-GSP boot path staged the message queue but never queued the two fire-and-forget init RPCs the production client places in it before the booter starts. GSP-RM therefore created its GPU object without any system information and aborted RM init (live GSP_INIT_DONE rpc_result=0x59), with the resource-manager's object-database lookups asserting from the first journal record. Submit function 72 (GSP_SET_SYSTEM_INFO, 928-byte v17_00 payload carrying the BAR physical bases, domain/bus/slot, PCI IDs, the BAR0 config-mirror offset, link/FLR capabilities and upstream-port flags read from the pci_dev) and function 73 (SET_REGISTRY, header-only empty table, which the server explicitly accepts) through the existing submit-only queue producer after all stage-3d preconditions and before the GSP falcon reset/Booter Load kick. The wire layouts are re-declared in the module with per-field static asserts against the reference ABI; payloads are heap-allocated, so no new stack frames are introduced.
* docs: record next-cycle readiness for the physical GSP bootArthur Hanson Rasmusson11 days
| | | | STATE-CURRENT and the integration page reflect the implemented sequencer, clean-shutdown RPC and static-info probe awaiting the next supervised live cycle.
* gsp-phys: command-queue TX and the GSP-RM unload RPC for clean teardownArthur Hanson Rasmusson11 days
| | | | Adds a minimal msgq producer on the command queue (element layout, checksum, sequence, dma_wmb before writePtr, doorbell) and submits the UNLOADING_GUEST_DRIVER RPC so GSP-RM shuts down and sets the scratch14 handoff bit the Booter Unload gate needs. Release attempts the RPC once before quiescing when a boot ran; on-demand testing is available through the debugfs file gsp-phys-unload-rpc while the module owns the GPU. GSP-RM processor suspend is polled on the GSP mailbox.
* docs: record the first real GSP boot and the live GSP-RM sessionArthur Hanson Rasmusson11 days
| | | | STATE-CURRENT and the architecture docs now describe the observed order (FWSEC -> Booter Load -> RISC-V active -> event 0x1002 run-sequencer -> 0x1001 init-done), the four-handoff-bit clean-release constraint, and the --boot/--keep harness contract.
* docs: refresh status wording after the 64/64 baseline and the ↵Arthur Hanson Rasmusson11 days
| | | | physical-backend lock
* docs: record the board power-domain hazard and D0-lock mitigation for the ↵Arthur Hanson Rasmusson11 days
| | | | | | | | | | | | | | | | | | | | | | physical backend - New 4.2: describe behaviourally how the option-D claim path can power-gate the board on driver release (platform power resource behind the root port, off/on sequence via the embedded controller), the two observed host freezes (no crash record), and the D0 lock now applied across release -> claim -> rebind: runtime-PM forbid + D3cold disable on the GPU, its board companion functions and the root port, config-space verification while claimed and again before rebind, abort with the locks held on any power-loss signature, runtime-PM restore after the distribution driver's probe. - 4.1/4.3: the lock is a required ownership step; returning to the normal driver is conditional, not assumed; real GSP boot not started. - 2/3(A): fresh no-unbind evidence - no exported RM/vGPU symbols and no manager daemon in the stock distribution build. - 6: driver-API baseline re-verified 64/64; ownership + firmware staging verified; power-domain lock implemented pending supervised verification. - 7/8: residual out-of-band power-cut risk, supervised-test requirement, and the gsp_phys_gpu + gsp_phys_hazard_ack operating constraint.
* docs: execution-backend bring-up staged - ownership and firmware staging ↵Arthur Hanson Rasmusson11 days
| | | | verified, real boot next
* 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
* docs: add the full-system picture and interaction/scheduling diagramsArthur Hanson Rasmusson13 days
| | | | | | | | | | | | | | - new 03-architecture/09-full-system-picture.md: end-state map, GSP boot, guest init, RPC lifecycle, memory model, work path (bridge and end state), scheduling, isolation levels, KVM/mdev/VFIO, BAR/engine/channel/GMMU, portability, performance model, implementation/test status - new 03-architecture/10-interaction-and-scheduling.md: interaction inventory, control-plane call path, msgq element lifecycle, channel pump, concurrency, timing budgets, multi-tenant scheduling, teardown ordering, versioning - README: mermaid system diagram replaces the ASCII block; reading list extended and renumbered - component docs: GSP boot sequence, mdev/VFIO lifecycle, end-state interaction sequence; STATE-CURRENT links
* docs: record physical-GPU integration mechanism and refresh project statusArthur Hanson Rasmusson13 days
| | | | | | | | | | | - add docs/03-architecture/08-physical-gpu-integration.md: interfaces that exist, mechanism options A-E, chosen path (module-owned GPU driven through its real GSP firmware), sharing policy, decision record - update 06-host-module-and-hybrid-model, 02-practical-challenges, system overview, known-knowns, docs/README reading order and CUDA-side docs to match - correct stale engine-topology/COPY14 blocker claims across the tree - add STATE-CURRENT.md as the dated public status snapshot
* docs/uvm: describe the push-execution fallbacks and the semaphore-VA flap ↵Arthur Hanson Rasmusson2026-09-26
| | | | pitfall
* kernel: validate learned semaphore maps and post guest GPU eventsArthur Hanson Rasmusson2026-09-24
| | | | | | | | | | | | | | | - admit {GPU VA -> PA} pairs only when the preceding bytes form a valid client memory descriptor header (type 0/1, CPU+GPU mapped bits), prefer validated pairs over headerless candidates under first-wins dedup, and invalidate the translation cache on every rebuild; fixes stale identity entries shadowing live pool pages and lets the guest UVM channel bring-up complete on its own - capture OS event allocations (class 0x79) and post event records (function 0x1003) into the guest status queue when a channel's busy notification is consumed, with a broadcast fallback, serialized with replies via a queue lock - add BAR0 shadow introspection (dump_bar0/scan_bar0) and guest-side diagnostic scripts for the VM cycle
* docs: merge the legacy flat documents, add the CUDA deep-dive and link checksArthur Hanson Rasmusson2026-09-23
| | | | | | | | | | | | | | | | | | | | | | * Merge and remove the pre-reboot flat documents, preserving their still-useful material in the structured tree: debugging workflows and the EPT-livelock case study (05-operations/02), performance microbenchmarks and A/B methodology (05-operations/01), the version-upgrade runbook (05-operations/02 section 4, with corrected host/guest framing), kernel-code pitfalls (07-developers) and the OpenRM build/load order (03-architecture/06 section 7). The remaining legacy files were verified redundant and removed. * docs/README now records where each migrated topic lives. * Portability: the config YAML files are called out as design targets that no code reads yet, with what adding support actually requires today. * Getting started: the OpenRM step is marked optional (native vGPU-management workflows only; the emulated path uses the distro driver). * tools docs: rmtool/rmtop marked as planned, pointing at the implemented tools/rmq subset. * wiki: new CUDA-Userspace-Driver deep-dive page (public-safe, links the canonical userspace/cuda analysis) and index update. * scripts/check-docs-links.py plus a CI step so relative links cannot rot. * STATE.md references to removed documents repointed.
* docs: refresh status, supersede stale material, link the CUDA analysisArthur Hanson Rasmusson2026-09-23
| | | | | | | | | | | | | | | | | | | | | | | | * Status now matches the live state: guest driver probe and nvidia-smi work; cuInit/device queries work; cuCtxCreate returns 999 because the emulated engine list is missing the async copy engine (COPY14). The userspace libcuda segfault is recorded as solved, with its mechanism (an RM allocation reply must echo request parameters; zeroing them corrupted the caller's saved frame pointer). * Correct the emulation claims: only a subset of RM controls are special-cased; the rest return a success reply with zeroed parameters whose consumed fields are still being corrected; allocation replies are coherent but no server-side object model exists. * Add the eight-point emulation checklist and reply-fidelity ladder as explicit gates, documented in userspace/cuda and linked from the architecture, implementation and operations docs. * Fix operational errors: build/test commands, module load order, mdev type names, LFS references, debugfs claims, in-repo firmware claims, CI claims, portability matrix (guest status, config layout, userspace driver facts). * Mark historical material: one superseded banner per legacy document with a pointer to its replacement; STATE.md marked as a 2026-09-21 snapshot. * Wiki: fix the index, add status banners and in-place factual corrections (msgq transport vs legacy mailbox, BAR definitions, error statuses, migration, glossary), and note the archived 2023 imports.
* Untrack legacy trees and purely legacy docs (kept locally)Arthur Hanson Rasmusson2026-09-23
| | | | | | | | | - patches/ -> legacy-patches/ (gitignored) - legacy-driver-guest/ (old guest vGPU driver, gitignored) - docs/old/ (superseded architecture write-up, gitignored) - docs that only reference the legacy components stay tracked; their path references now point at legacy-patches/ - install.sh PATCH_DIR updated
* Open-IOV: initial public releaseOpen-IOV2026-09-23
Open-IOV virtualizes NVIDIA GPUs so that unmodified guest drivers run with real GPU functionality - CUDA first, 3D and video to follow - on unmodified hosts, without a proprietary vGPU license and without patching any driver, firmware or hypervisor. Core principle: emulate the interface, pass through the work. kernel/ open-iov-vfio.ko - host VFIO mdev driver: virtual GPU device (PCI config space, BAR shadows, MSI-X), GSP boot emulation, GSP-RM message-queue/RPC emulation, memory model (GPU-VA to guest-PA discovery) and the semaphore-completion service that advances guest UVM progress. userspace/ libiov.so management API and examples. tools/ guest diagnostics, firmware analysis wrappers, RM probes. scripts/ stack manager, VM harness, build/load/test automation. config/ hardware/version profiles (the portability surface). docs/ documentation tree - start at docs/README.md. wiki/ long-form firmware and protocol deep dives. Status: initialization works end to end for a stock 570.144 Linux guest on Turing (TU104): driver probe, nvidia-smi, the full GSP-RM control battery, object creation and the early CUDA/UVM start-up path. GPU work forwarding - the step that makes CUDA kernels execute on real hardware - is the active work item; see docs/04-implementation/01-known-knowns-and-unknowns.md. License: BSD-3-Clause for the project; GPL-2.0 for kernel modules that link GPL-only kernel interfaces. See LICENSE and docs/09-reference/legal-and-licensing.md.
generated by cgit v1.2.3 (git 2.39.1) at 2026-10-12 11:38:32 +0000