1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
|
# 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-20, tree `master @ 16291c72`. 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 | `[live]` working — verified green on fresh boots: the vector-add (`VADD n=32768 bad=0`), matrix-multiply (`MATMUL n=256 bad=0`) and transformer (`dh=256 seq=64 bad=0`, `FFN4 layers=4 bad=0`) clients print `STATUS OK`, engine-authored completions relay to the guest and its synchronisation waits resolve. Remaining: the large-buffer staged-transfer class is under repair (some large multi-chunk clients still mis-verify); fresh-boot re-measurement is in progress after the boot-poisoning fix; per-guest execution isolation for simultaneous CUDA guests is in progress |
| Physical backend on real hardware (module-owned GPU running its real GSP-RM) | `[live]` boot, RPC session, object creation, copy-engine work and GR execution proven — the verified guest CUDA kernel clients execute through this backend |
| Multi-tenant isolation (mdev per VM, per-context page directories) | `[wip]` device-level coexistence works — multiple mediated devices with different emulated VRAM sizes and multiple guests coexist; per-guest execution isolation for simultaneous CUDA guests 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 — demonstrated: the verified clients execute on
the physical engine and the engine-authored completions relay to the guest.
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 — the
GR completion path now relays (engine-authored releases wake the guest's
synchronisation waits); fault semantics remain partial.
6. Reproducibility: every boot, not a lucky one — root-caused and fixed (the
boot-poisoning defect: the wrong status-queue consumption cursor could
desynchronise the reply ring under load and poison the boot);
re-measurement across fresh boots is in progress.
7. No ad-hoc default-off parameters required for the canonical path — still
open.
Until every gate holds, the honest formulation is: **initialization, the
driver-API path and kernel execution on the physical GPU work and verify;
hardening (large-buffer transfers, boot-to-boot reproducibility) and
per-guest isolation remain.**
## 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 guest CUDA kernels executing and verifying on the
physical GPU. 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, its resolved theories and its open work, 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)
|
