diff options
Diffstat (limited to 'wiki/Project-Status.md')
| -rw-r--r-- | wiki/Project-Status.md | 81 |
1 files changed, 81 insertions, 0 deletions
diff --git a/wiki/Project-Status.md b/wiki/Project-Status.md new file mode 100644 index 0000000..d6e60d1 --- /dev/null +++ b/wiki/Project-Status.md @@ -0,0 +1,81 @@ +# Project Status + +> **What this page is.** The honest, dated state of the project: what works +> today, what is in progress, and what is not started. It is refreshed +> periodically and each claim maps to a maintained document in the repository. +> Canonical sources: [`../docs/README.md`](../docs/README.md) (project front +> door), [`../docs/04-implementation/01-known-knowns-and-unknowns.md`](../docs/04-implementation/01-known-knowns-and-unknowns.md) +> (known-knowns and known-unknowns) and +> [`../docs/04-implementation/03-execution-frontier.md`](../docs/04-implementation/03-execution-frontier.md) +> (the execution frontier). When this page and the docs disagree, the docs tree +> wins. + +Status: 2026-10-12, tree `master @ 2f066727`. Tags: `[live]` proven with the +stock guest driver; `[gated]` implemented, default-off or behind supervised +gates; `[wip]` partially implemented; `[wall]` current blocker; `[target]` +named success state; `[planned]` designed, not built. + +## 1. Milestone ladder + +| Milestone | State | +|---|---| +| Emulated vGPU device (PCI, BARs, MSI-X, VFIO mdev) | `[live]` working | +| GSP boot emulation (FWSEC / booter / RISCV handshake) | `[live]` working | +| GSP-RM message queues and RPC transport | `[live]` working | +| Stock guest driver probe and `nvidia-smi` (TU104) | `[live]` working | +| CUDA userspace init and the driver-API smoke (`cuInit`, device enumeration, `cuCtxCreate`, allocation, copies, free, destroy) | `[live]` working — the smoke prints `ALL OK` and the 64-byte payload round-trips exactly | +| Guest CUDA kernel execution on real hardware | `[wall]` a forwarded guest launch reaches the engine queue (the front end deposits the methods and the scheduling path accepts them), but the engine does not yet execute the forwarded launch descriptor — an engine-authored release has not been observed. Emulation-mode kernel runs (executed through the host bridge on a no-claim path) have completed green; reproducibility of the green path across boots is an open issue | +| Physical backend on real hardware (module-owned GPU running its real GSP-RM) | `[live]` boot, RPC session, object creation and copy-engine work proven; GR execution is the same frontier as above | +| Multi-tenant isolation (mdev per VM, per-context page directories) | `[wip]` designed; the baseline service-state ownership work is in progress | +| OpenGL / Vulkan (3D), video | `[planned]` | +| Windows guests | `[planned]` (target) | +| Xen / Argo / OpenXT / Qubes Air transports | `[planned]` (the emulation core is hypervisor-independent by construction) | +| Live migration | `[planned]` | +| Performance numbers | `[planned]` — no published numbers yet; any claim will ship with its measurement methodology | + +## 2. What "CUDA works" means here + +A green `nvidia-smi` or even a passing driver-API smoke is not "CUDA works". +The project's definition of done for CUDA requires all of the following +([`../docs/04-implementation/01-known-knowns-and-unknowns.md`](../docs/04-implementation/01-known-knowns-and-unknowns.md)): + +1. Stock guest driver probe, `nvidia-smi`, device enumeration — done. +2. Context creation and the full driver-API surface (`cuMemAlloc`, copies, + free, destroy) — done. +3. A guest kernel launch that **executes on real hardware** and is proven by an + engine-authored completion — the current frontier. +4. Memory the guest's work refers to resolving correctly end to end (the VA↔PA + model) — partially, for the paths exercised so far. +5. Correct completion, semaphore and fault semantics back to the guest — CE + class work has the relay; GR is open. +6. Reproducibility: every boot, not a lucky one — an open issue. +7. No ad-hoc default-off parameters required for the canonical path. + +Until every gate holds, the honest formulation is: **initialization and the +driver-API path work; engine execution is in progress.** + +## 3. How to see it yourself + +The reference setup takes about half an hour from a fresh host +([`Install-and-First-Run.md`](Install-and-First-Run.md)); the current expected +outcome is exactly the ladder above — driver probe, `nvidia-smi`, the full +driver-API smoke, and the execution frontier where it stands. The +risc-v-gsp-rm-debugger workbench +([`Riscv-GSP-RM-Debugger.md`](Riscv-GSP-RM-Debugger.md)) is the host-side +tooling used to study the firmware side of that frontier. + +## 4. How this page is maintained + +Every claim above carries a date and a tag, maps to a maintained document in +the repository, and is refreshed as milestones land. The execution story, with +its evidence and its open theories, is on +[`Execution-Frontier.md`](Execution-Frontier.md). + +## 5. Related pages + +* [`Install-and-First-Run.md`](Install-and-First-Run.md) +* [`System-Overview.md`](System-Overview.md) +* [`Execution-Frontier.md`](Execution-Frontier.md) +* [`Hardware-Software-Matrix.md`](Hardware-Software-Matrix.md) — which + hardware and software combinations are Reference, Target or Experimental. +* [`FAQ.md`](FAQ.md) |