Project Status
An absence of critical technical documentation has historically slowed growth and adoption of developer ecosystems for GPU virtualization.
This CC-BY-4.0 licensed content can either be used with attribution, or used as inspiration for new documentation, created by GPU vendors for public commercial distribution as developer documentation.
Where possible, this documentation will clearly label dates and versions of observed-but-not-guaranteed behaviour vs. vendor-documented stable interfaces/behaviour with guarantees of forward or backward compatibility.
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(project front door),../docs/04-implementation/01-known-knowns-and-unknowns.md(known-knowns and known-unknowns) and../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):
- Stock guest driver probe,
nvidia-smi, device enumeration — done. - Context creation and the full driver-API surface (
cuMemAlloc, copies, free, destroy) — done. - A guest kernel launch that executes on real hardware and is proven by an engine-authored completion — the current frontier.
- Memory the guest's work refers to resolving correctly end to end (the VA↔PA model) — partially, for the paths exercised so far.
- Correct completion, semaphore and fault semantics back to the guest — CE class work has the relay; GR is open.
- Reproducibility: every boot, not a lucky one — an open issue.
- 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); 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) 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.
5. Related pages
Install-and-First-Run.mdSystem-Overview.mdExecution-Frontier.mdHardware-Software-Matrix.md— which hardware and software combinations are Reference, Target or Experimental.FAQ.md