Difference between revisions of "Project Status"
Jump to navigation
Jump to search
m (Status refresh 2026-10-20: guest CUDA kernels execute on the physical GPU (vector-add/matmul/transformer green); boot-poisoning defect fixed) |
m (2026-10-30 wiki refresh: goals, GSP, graphics, performance, interfaces) |
||
| Line 5: | Line 5: | ||
<blockquote>'''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: [https://git.vgpu.io/open-iov.git/tree/docs/README.md <code>../docs/README.md</code>] (project front door), [https://git.vgpu.io/open-iov.git/tree/docs/04-implementation/01-known-knowns-and-unknowns.md <code>../docs/04-implementation/01-known-knowns-and-unknowns.md</code>] (known-knowns and known-unknowns) and [https://git.vgpu.io/open-iov.git/tree/docs/04-implementation/03-execution-frontier.md <code>../docs/04-implementation/03-execution-frontier.md</code>] (the execution frontier). When this page and the docs disagree, the docs tree wins.</blockquote> | <blockquote>'''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: [https://git.vgpu.io/open-iov.git/tree/docs/README.md <code>../docs/README.md</code>] (project front door), [https://git.vgpu.io/open-iov.git/tree/docs/04-implementation/01-known-knowns-and-unknowns.md <code>../docs/04-implementation/01-known-knowns-and-unknowns.md</code>] (known-knowns and known-unknowns) and [https://git.vgpu.io/open-iov.git/tree/docs/04-implementation/03-execution-frontier.md <code>../docs/04-implementation/03-execution-frontier.md</code>] (the execution frontier). When this page and the docs disagree, the docs tree wins.</blockquote> | ||
Status: 2026-10- | Status: 2026-10-30, tree <code>master @ b4930168</code>. Tags: <code>[live]</code> proven with the stock guest driver; <code>[gated]</code> implemented, default-off or behind supervised gates; <code>[wip]</code> partially implemented; <code>[wall]</code> current blocker; <code>[target]</code> named success state; <code>[planned]</code> designed, not built. | ||
== 1. Milestone ladder == | == 1. Milestone ladder == | ||
| Line 30: | Line 30: | ||
|- | |- | ||
| Guest CUDA kernel execution on real hardware | | Guest CUDA kernel execution on real hardware | ||
| <code>[live]</code> working — verified green on fresh boots: the vector-add (<code>VADD n=32768 bad=0</code>), matrix-multiply (<code>MATMUL n=256 bad=0</code>) and transformer (<code>dh=256 seq=64 bad=0</code>, <code>FFN4 layers=4 bad=0</code>) clients print <code>STATUS OK</code>, engine-authored completions relay to the guest and its synchronisation waits resolve. Remaining: the | | <code>[live]</code> working — verified green on fresh boots: the vector-add (<code>VADD n=32768 bad=0</code>), matrix-multiply (<code>MATMUL n=256 bad=0</code>) and transformer (<code>dh=256 seq=64 bad=0</code>, <code>FFN4 layers=4 bad=0</code>) clients print <code>STATUS OK</code>, engine-authored completions relay to the guest and its synchronisation waits resolve. A ring-block ownership defect that could stall the first client after a reboot was root-caused and fixed. Remaining: the staged-transfer class (some large multi-chunk clients still mis-verify; the failure modes are proven and under repair) and per-guest execution isolation for simultaneous CUDA guests | ||
|- | |- | ||
| Physical backend on real hardware (module-owned GPU running its real GSP-RM) | | Physical backend on real hardware (module-owned GPU running its real GSP-RM) | ||
| <code>[live]</code> boot, RPC session, object creation, copy-engine work and GR execution proven — the verified guest CUDA kernel clients execute through this backend | | <code>[live]</code> boot, RPC session, object creation, copy-engine work and GR execution proven — the verified guest CUDA kernel clients execute through this backend, and graphics method streams execute on the engine in two lanes ([[Graphics Execution|<code>Graphics-Execution.md</code>]]) | ||
|- | |- | ||
| Multi-tenant isolation (mdev per VM, per-context page directories) | | Multi-tenant isolation (mdev per VM, per-context page directories) | ||
| <code>[wip]</code> 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 | | <code>[wip]</code> device-level coexistence works — multiple mediated devices with different emulated VRAM sizes and multiple guests coexist (two guests demonstrated); per-guest execution isolation for simultaneous CUDA guests is in progress | ||
|- | |- | ||
| OpenGL / Vulkan (3D), | | OpenGL (3D graphics) | ||
| <code>[wip]</code> — the X server and GLX run on the emulated vGPU with the stock driver, the engine executes real GL method streams (verbatim 3D replay plus synthesized launches), and a direct GL client creates its channels and readback path; rendered (non-black) frames are the frontier ([[OpenGL|<code>OpenGL.md</code>]]) | |||
|- | |||
| Vulkan (3D/compute) | |||
| <code>[wip]</code> — the guest Vulkan pipeline runs end to end on the emulated vGPU (device, allocation, pipeline, command buffer, fence, queue submit, readback) and the engine executes translated launches; frames are still black — program delivery and program-VA mapping are the frontier ([[Vulkan|<code>Vulkan.md</code>]]) | |||
|- | |||
| DirectX / Windows guests | |||
| <code>[planned]</code> (target) — no Windows guest booted yet; the architecture is the same emulation target ([[DirectX|<code>DirectX.md</code>]]) | |||
|- | |||
| Video (NVENC/NVDEC) | |||
| <code>[planned]</code> | | <code>[planned]</code> | ||
|- | |- | ||
| Xen / Argo / OpenXT / Qubes Air transports | | Xen / Argo / OpenXT / Qubes Air transports | ||
| Line 63: | Line 69: | ||
# Memory the guest's work refers to resolving correctly end to end (the VA↔PA model) — partially, for the paths exercised so far. | # 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 — the GR completion path now relays (engine-authored releases wake the guest's synchronisation waits); fault semantics remain partial. | # 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. | ||
# Reproducibility: every boot, not a lucky one — root | # Reproducibility: every boot, not a lucky one — two root causes landed: the boot-poisoning defect (the wrong status-queue consumption cursor could desynchronise the reply ring under load) and the ring-block ownership defect that could stall the first client after a reboot. Green clients are reproduced across fresh boots; a formal every-boot acceptance campaign is the remaining work. | ||
# No ad-hoc default-off parameters required for the canonical path — still open. | # No ad-hoc default-off parameters required for the canonical path — still open (the forwarding and graphics seams remain parameterised while they are validated). | ||
Until every gate holds, the honest formulation is: '''initialization, the driver-API path and kernel execution on the physical GPU work and verify; | Until every gate holds, the honest formulation is: '''initialization, the driver-API path and kernel execution on the physical GPU work and verify; the staged-transfer class, per-guest isolation and the graphics pixel frontier remain.''' | ||
== 3. How to see it yourself == | == 3. How to see it yourself == | ||
The reference setup takes about half an hour from a fresh host ([[Install and First Run|<code>Install-and-First-Run.md</code>]]); the current expected outcome is exactly the ladder above — driver probe, <code>nvidia-smi</code>, the full driver-API smoke, and guest CUDA kernels executing and verifying on the physical GPU. The risc-v-gsp-rm-debugger workbench ([[risc-v-gsp-rm-debugger|<code>Riscv-GSP-RM-Debugger.md</code>]]) is the host-side tooling used to study the firmware side of that frontier. | The reference setup takes about half an hour from a fresh host ([[Install and First Run|<code>Install-and-First-Run.md</code>]]); the current expected outcome is exactly the ladder above — driver probe, <code>nvidia-smi</code>, the full driver-API smoke, and guest CUDA kernels executing and verifying on the physical GPU. On the graphics side the same setup brings up the X server and GLX on the emulated vGPU ([[OpenGL|<code>OpenGL.md</code>]]). The risc-v-gsp-rm-debugger workbench ([[risc-v-gsp-rm-debugger|<code>Riscv-GSP-RM-Debugger.md</code>]]) is the host-side tooling used to study the firmware side of that frontier. | ||
== 4. How this page is maintained == | == 4. How this page is maintained == | ||
Latest revision as of 17:06, 30 October 2026
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-30, tree master @ b4930168. 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. A ring-block ownership defect that could stall the first client after a reboot was root-caused and fixed. Remaining: the staged-transfer class (some large multi-chunk clients still mis-verify; the failure modes are proven and under repair) and per-guest execution isolation for simultaneous CUDA guests
|
| 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, and graphics method streams execute on the engine in two lanes (Graphics-Execution.md)
|
| 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 (two guests demonstrated); per-guest execution isolation for simultaneous CUDA guests is in progress
|
| OpenGL (3D graphics) | [wip] — the X server and GLX run on the emulated vGPU with the stock driver, the engine executes real GL method streams (verbatim 3D replay plus synthesized launches), and a direct GL client creates its channels and readback path; rendered (non-black) frames are the frontier (OpenGL.md)
|
| Vulkan (3D/compute) | [wip] — the guest Vulkan pipeline runs end to end on the emulated vGPU (device, allocation, pipeline, command buffer, fence, queue submit, readback) and the engine executes translated launches; frames are still black — program delivery and program-VA mapping are the frontier (Vulkan.md)
|
| DirectX / Windows guests | [planned] (target) — no Windows guest booted yet; the architecture is the same emulation target (DirectX.md)
|
| Video (NVENC/NVDEC) | [planned]
|
| 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 — demonstrated: the verified clients execute on the physical engine and the engine-authored completions relay to the guest.
- 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 — the GR completion path now relays (engine-authored releases wake the guest's synchronisation waits); fault semantics remain partial.
- Reproducibility: every boot, not a lucky one — two root causes landed: the boot-poisoning defect (the wrong status-queue consumption cursor could desynchronise the reply ring under load) and the ring-block ownership defect that could stall the first client after a reboot. Green clients are reproduced across fresh boots; a formal every-boot acceptance campaign is the remaining work.
- No ad-hoc default-off parameters required for the canonical path — still open (the forwarding and graphics seams remain parameterised while they are validated).
Until every gate holds, the honest formulation is: initialization, the driver-API path and kernel execution on the physical GPU work and verify; the staged-transfer class, per-guest isolation and the graphics pixel frontier remain.
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 guest CUDA kernels executing and verifying on the physical GPU. On the graphics side the same setup brings up the X server and GLX on the emulated vGPU (OpenGL.md). 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, its resolved theories and its open work, 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