From 260c73e72674d55bf8f082c0e1011075a0365a78 Mon Sep 17 00:00:00 2001 From: Arthur Hanson Rasmusson Date: Fri, 2 Oct 2026 11:28:49 -0400 Subject: docs: engineering-operations playbook and project-wide status accuracy pass - 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). --- docs/03-architecture/01-system-overview.md | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) (limited to 'docs/03-architecture/01-system-overview.md') diff --git a/docs/03-architecture/01-system-overview.md b/docs/03-architecture/01-system-overview.md index 5c2ba6c..fa328ae 100644 --- a/docs/03-architecture/01-system-overview.md +++ b/docs/03-architecture/01-system-overview.md @@ -60,7 +60,7 @@ HOST MODULE open-iov-vfio.ko ├─ virtual device: config space, BAR0/BAR1/BAR3 windows, MSI-X ├─ emulation core: GSP boot + GSP-RM (RPC msgq, controls, objects, events) ├─ memory model: guest RAM access, VA↔PA maps, VRAM backing - └─ work path: channel/push forwarding to the physical GPU [goal; software bridge today] + └─ work path: channel/push forwarding to the physical GPU [CE copies forwarded (default off); GR open] │ module-owned device + real GSP session HOST BACKEND the GPU's own hardware + GSP firmware, driven by this module │ (the distribution nvidia.ko stays unmodified and unbound in @@ -170,10 +170,12 @@ decompiled and mapped (see `wiki/GSP-570.144W-Firmware-Analysis.md` and without server-side object management. Where the driver consumes a reply value, that value is still being corrected (the reply-fidelity ladder). 5. `nvidia-smi -L` enumerates the emulated device and CUDA user-space starts - (`cuInit` / `cuDeviceGetCount` / `cuDeviceGet` succeed). The client reaches - `cuCtxCreate`, which currently ends in a forced `rc=999` on a completion - wait; the copy-engine method streams execute in software as a bridge, and - the execution backend is not built yet (see + (`cuInit` / `cuDeviceGetCount` / `cuDeviceGet` succeed); context creation + completes and the full CUDA driver-API smoke passes (`ALL OK` 64/64, copies + matched). The execution backend is live: CE-class copies are + forwarded to the physical copy engine (default off) with engine-authored + semaphore releases and a fault relay; kernel execution is blocked on GR + engine-context validity (see [`08-physical-gpu-integration.md`](08-physical-gpu-integration.md)). The CUDA-side contract and the reply-fidelity rules are documented in -- cgit v1.2.3