diff options
Diffstat (limited to 'docs/README.md')
| -rw-r--r-- | docs/README.md | 64 |
1 files changed, 50 insertions, 14 deletions
diff --git a/docs/README.md b/docs/README.md index 61aa529..77f4069 100644 --- a/docs/README.md +++ b/docs/README.md @@ -98,7 +98,10 @@ and [`01-orientation/02-the-ai-edge-and-ecosystem.md`](01-orientation/02-the-ai- ## 3. Where is the project today? -**Honest status (2026-10-01):** +**Honest status (2026-10-02):** + +A dated snapshot of this status, refreshed on every progress check, is kept at +[`../STATE-CURRENT.md`](../STATE-CURRENT.md). | Area | State | |------|-------| @@ -107,8 +110,8 @@ and [`01-orientation/02-the-ai-edge-and-ecosystem.md`](01-orientation/02-the-ai- | GSP-RM message queue + RPC transport | ✅ Working | | GSP-RM controls: device/fb/bus tables, CE caps, vaspace, GMMU static info | 🟡 Mostly — the engine inventory now includes the async copy engine and the CE capabilities match the device; reply fidelity for the remaining consumed fields is still being tightened | | Guest `nvidia.ko` probe, `nvidia-smi` | ✅ Working (TU104) | -| Guest CUDA driver (`libcuda`) startup | ✅ Driver-API baseline — `cuInit`, device enumeration, `cuCtxCreate`, `cuMemAlloc`, copies, free and destroy complete end to end; the smoke test prints `ALL OK` and the 64-byte payload round-trips exactly (64/64, re-verified 2026-10-01 on the current build). See [`04-implementation/01-known-knowns-and-unknowns.md`](04-implementation/01-known-knowns-and-unknowns.md) and [`../userspace/cuda/READ-ME-FIRST.md`](../userspace/cuda/READ-ME-FIRST.md) | -| CUDA kernel execution | 🟡 The backend is live: the module owns the physical GPU and its real GSP-RM initialized, serves the full static-config reply and shuts down cleanly; a host resource-manager client now allocates memory/VAS/page-directory/TSG/channel and has executed the first real copy on the physical copy engine (4 KiB, semaphore released, dst==src, 2026-10-01). What remains is wiring that session into the guest-facing path so guest submissions execute there ([`03-architecture/11-physical-backend-guest-wiring.md`](03-architecture/11-physical-backend-guest-wiring.md)); see also [`03-architecture/08-physical-gpu-integration.md`](03-architecture/08-physical-gpu-integration.md) | +| Guest CUDA driver (`libcuda`) startup | ✅ Driver-API baseline — `cuInit`, device enumeration, `cuCtxCreate`, `cuMemAlloc`, copies, free and destroy complete end to end; the smoke test prints `ALL OK` and the 64-byte payload round-trips exactly (64/64, re-verified 2026-10-02 on the current build). See [`04-implementation/01-known-knowns-and-unknowns.md`](04-implementation/01-known-knowns-and-unknowns.md) and [`../userspace/cuda/READ-ME-FIRST.md`](../userspace/cuda/READ-ME-FIRST.md) | +| CUDA kernel execution | 🟡 Copy-engine-class guest copies and their releases are forwarded to the real hardware with release and fault relay in place (parameters default off); GR (graphics/compute) execution is the open wall — the host GR ladder brings up a GR0 channel with a compute-class object, but its first push faults on a context that was never committed. The device is currently held in the designed locked fail-safe awaiting a supervised reboot. See [`03-architecture/11-physical-backend-guest-wiring.md`](03-architecture/11-physical-backend-guest-wiring.md), [`03-architecture/08-physical-gpu-integration.md`](03-architecture/08-physical-gpu-integration.md) and [`../STATE-CURRENT.md`](../STATE-CURRENT.md) | | OpenGL / Vulkan | 🔴 Not yet | | Windows guest | 🔴 Not yet | | Multi-tenant isolation (VFs, mdev-per-VM) | 🟡 Designed, partially implemented | @@ -118,14 +121,16 @@ the userspace `libcuda` segfault was fixed (an RM allocation reply now echoes the request parameters instead of returning zeros), the engine inventory is complete, and the driver-API smoke test now completes end to end — `cuCtxCreate` returns and the 64-byte payload round-trips exactly (64/64, re-verified -2026-10-01 on the current build). The full +2026-10-02 on the current build). The full mechanism, with offsets and the decompiled call path, is in [`../userspace/cuda/docs/05-570.144-decompilation.md`](../userspace/cuda/docs/05-570.144-decompilation.md). -The remaining frontier is guest-facing execution: the runtime client initializes -and queues a kernel launch, and the physical backend now executes real work (the -first copy-engine transfer completed on hardware — 4 KiB with the semaphore -released and dst==src, 2026-10-01) — but the two planes are not yet wired -together. The backend, a module-owned GPU running its real GSP firmware as the +The remaining frontier is guest-facing execution: copy-engine-class copies and +their releases are forwarded to real hardware with release relay and fault +relay in place (parameters default off); GR execution is the open wall — the +host GR ladder brings up a GR0 channel with a compute-class object, but its +first push faults on an engine context that was never committed. The device is +currently held in the designed locked fail-safe awaiting a supervised reboot. +The backend, a module-owned GPU running its real GSP firmware as the resource-manager server, is specified in [`03-architecture/08-physical-gpu-integration.md`](03-architecture/08-physical-gpu-integration.md); the bridge from the live session to the guest-facing mdev/VFIO path is specified @@ -170,16 +175,36 @@ Read in order if you are new. Jump directly if you know what you need. | 18 | [Performance, correctness, security](05-operations/01-performance-correctness-security.md) | developers, auditors | 25 min | | 19 | [Debugging and maintenance workflows](05-operations/02-debugging-and-maintenance-workflows.md) | developers, maintainers | 25 min | | 20 | [GSP in a RISC-V VM (green-eye, experimental)](05-operations/03-risc-v-gsp-rm-vm.md) — **# TOOL IN DEVELOPMENT - NOT READY YET!** | developers, analysts | 15 min | -| 21 | [Hardware and software matrix](06-portability/hardware-software-matrix.md) | developers, integrators | 20 min | -| 22 | [Developer onboarding and standards](07-developers/onboarding-and-standards.md) | contributors | 20 min | -| 23 | [HAAEEP and collaboration](08-ecosystem/haaeep-and-collaboration.md) | stakeholders, partners | 20 min | -| 24 | [Glossary and FAQ](09-reference/glossary-and-faq.md) | everyone | reference | +| 21 | [green-eye user guide (experimental)](05-operations/04-green-eye-user-guide.md) — **# TOOL IN DEVELOPMENT - NOT READY YET!** | developers, analysts | 15 min | +| 22 | [Defensive Operations Runbook](RUNBOOK.md) | maintainers, operators | 20 min | +| 23 | [Engineering operations](eng-ops.md) — tool admission and workflows (Part I) plus live physical-backend operations (Part II) | maintainers, developers | 20 min | +| 24 | [Hardware and software matrix](06-portability/hardware-software-matrix.md) | developers, integrators | 20 min | +| 25 | [Developer onboarding and standards](07-developers/onboarding-and-standards.md) | contributors | 20 min | +| 26 | [HAAEEP and collaboration](08-ecosystem/haaeep-and-collaboration.md) | stakeholders, partners | 20 min | +| 27 | [Glossary and FAQ](09-reference/glossary-and-faq.md) | everyone | reference | + +<!-- change (2026-10-02): insert the green-eye user guide and the Open-IOV +Defensive Operations Runbook into the reading list; renumber rows 21-24 to +23-26; additive only. --> + +<!-- change (2026-10-02): insert the engineering-operations document into the +operations group; renumber rows 23-26 to 24-27; additive only. --> Row 15 is a **deferred future goal**: host NVIDIA-driver acceleration over a virtual function. The feasibility verdict and a first design sketch are recorded there for planning; it is not on the active critical path (guest CUDA execution, multi-VM, 3D, performance come first). +> **Tool documentation is under development.** The per-tool pages under +> [`tools/`](tools/README.md) (for example `rmtool.md` and `rmtop.md`) are +> being expanded; until they are complete, start with the +> [Defensive Operations Runbook](RUNBOOK.md) and the +> [green-eye user guide](05-operations/04-green-eye-user-guide.md). + +<!-- change (2026-10-02): state that the per-tool documentation section is +under development and point readers at the RUNBOOK and the green-eye user +guide; additive only. --> + Deep-dive material lives in [`../wiki/`](../wiki/README.md) (firmware decompilation record, address reference, historical protocol notes). Wiki pages that predate the current implementation carry a status banner naming @@ -191,6 +216,15 @@ The pre-reboot flat documents have been merged into this tree and removed * debugging: gdbstub/NMI workflows, the EPT-livelock case study and the failure taxonomy → [`05-operations/02-debugging-and-maintenance-workflows.md`](05-operations/02-debugging-and-maintenance-workflows.md) +* defensive operations: incident scenarios, the OODA ordering, evidence + bundles and the escalation tree → + [`RUNBOOK.md`](RUNBOOK.md); the green-eye quickstart, tool chooser and + troubleshooting → + [`05-operations/04-green-eye-user-guide.md`](05-operations/04-green-eye-user-guide.md) + +<!-- change (2026-10-02): point the post-merge document map at the new RUNBOOK +and green-eye user guide; additive only. --> + * firmware runtime analysis (experimental): running GSP/uproc firmware in a RISC-V QEMU VM with hooks, watchpoints, memory dumps and `gsp-rm-vfio` accuracy measurement — **# TOOL IN DEVELOPMENT - NOT READY YET!** → @@ -213,7 +247,9 @@ The pre-reboot flat documents have been merged into this tree and removed and [`06-portability/hardware-software-matrix.md`](06-portability/hardware-software-matrix.md). What remains historical is the pre-supersession wiki material and -`old/ARCHITECTURE.md`; their status banners name the canonical document. (The +`old/ARCHITECTURE.md`; the latter carries an explicit superseded banner +pointing at this page, and the older wiki pages carry status banners naming +the canonical document. (The former 2026-09-21 `STATE.md` snapshot is retired; its content lives on in the git history and its replacements above.) |