Main Page

Open-IOV is an open-source virtualization layer for NVIDIA GPUs: it runs stock, unmodified NVIDIA drivers inside virtual machines — Linux and Windows — with CUDA on hardware you own, without proprietary vGPU licenses, without patching the guest driver, the host driver, the hypervisor or the firmware.

Emulate the interface. Pass through the work. Never patch anyone.

The only new component is one host kernel module (vgsp.ko), which implements the interface the guest driver expects to talk to — the GPU System Processor and its resource-manager firmware — and arranges for the guest's work to run on real GPU hardware.

About Open-IOV · Community · Documentation

Start here

• Project Goals — what Open-IOV is for, and the status of each goal.
• Project Plan — how the work is sequenced, gated, and what is next.
• Project Status — the honest, dated state of the project.
• Install and First Run — fresh host to a stock guest driver in about half an hour.
• System Overview — how Open-IOV works, in one page.
• Documentation — the full index of this wiki.
• FAQ — the questions we get asked most.

Project status (2026-11-09)

Area	State
Emulated vGPU device (PCI, BARs, MSI-X, VFIO mdev)	Working
GSP boot emulation and GSP-RM message queues / RPC	Working
Stock guest driver probe, nvidia-smi (TU104)	Working
CUDA userspace init and the driver-API smoke (ALL OK, 64-byte payload round-trips)	Working
Guest CUDA kernel execution on real hardware	Working — vector-add, matrix-multiply and transformer kernels run green on fresh boots; the battery's staged-transfer class and per-guest isolation are in progress
Display and KMS (nvidia-modeset/NvKms, /dev/dri, X)	Working — the emulated display engine serves the modeset push buffers and notifier completion; NvKms registers, X settles and glxinfo reports OpenGL 4.6.0 with direct rendering
3D graphics: Xorg + OpenGL, Vulkan	In progress — the display/KMS and GL stacks run, the direct GL client's GR/CE channels submit and retire, the GSP event-IRQ fix completes swaps, and the guest's real GL draws now forward and execute on the physical GPU; the 2D path is green. The draw writes 0 pixels because its constant-buffer (MVP) page does not resolve, so constant-buffer content, MME/wedge stability and the X DDX push-buffer get-word/notifier completion are the current frontier — see Graphics Execution, OpenGL, Vulkan
Windows guests, multi-tenancy, migration, performance	Not yet — multiple mediated devices (different emulated VRAM sizes) and multiple guests already coexist; per-guest execution isolation is in progress

The full story, with evidence and the current wall: Project Status and The Execution Frontier.

Graphics

• Graphics Execution — how guest 3D work reaches the physical engines
• OpenGL — the stock guest GL stack on the emulated vGPU
• Vulkan — the guest Vulkan pipeline on the emulated vGPU
• DirectX — the Windows/DirectX target

Deep dives

• System Overview — the architecture before any subsystem
• Project Goals — mission, scope and goal-by-goal status
• GSP and GSP-RM — the firmware interface we emulate
• The vGSP Execution Plane (vEP) — how guest work becomes execution and completion
• The Host Module (vgsp.ko) — the module internals
• The Guest Stack and CUDASW — what runs unmodified in the guest
• CUDA Userspace Driver — the libcuda.so analysis
• Introduction to GMMU — GPU address translation from first principles
• UVM in the Guest — unified memory as a correctness oracle
• Physical GPU Backend and Guest Wiring — how work reaches real hardware
• The Execution Frontier — the leading edge, evidence-led
• Performance — the cost model, tracing and improvement programme
• Interfaces and Stability — which surfaces are contracts, which may change
• Guest Driver Lifecycle: A Field Guide — boot to CUDA with real IDs and log signatures

Firmware interoperability

• GSP 570.144W Firmware Analysis
• Address Reference
• RPC Message Format · BAR Emulation Specification · WPR Management · Migration Protocol · GSP RPC Emulation (historical, superseded)
• risc-v-gsp-rm-debugger — the firmware runtime workbench

Project and ecosystem

• Hardware and Software Matrix — supported combinations, honestly labelled
• HAAEEP and Collaboration — the agent-edge use case and how to work with us
• FAQ · Glossary

Community

• Source and issues: git.vgpu.io/open-iov
• Chat: Open-IOV Discord

About Open-IOV

Open-IOV runs unmodified NVIDIA driver stacks inside virtual machines with GPU compute on hardware you own — no proprietary vGPU license, and no patches to the guest driver, the host driver, the hypervisor or the firmware. The project adds one host kernel module (vgsp.ko) that implements the interface the guest driver expects to talk to — the GPU System Processor and its resource-manager firmware — and arranges for the guest's work to run on real GPU hardware.

• Mission: make NVIDIA GPUs fully virtualizable, by anyone, for any hypervisor, without modifying NVIDIA software, firmware or hardware.
• Principles: no patches anywhere; honest status carried with dated evidence; an independent, self-contained IP block; durability by owning the interface rather than a snapshot of it.
• Licensing: all documentation on this site is CC-BY-4.0; the project's code is BSD-3-Clause (GPL-2.0 for the kernel modules); NVIDIA software and firmware are used unmodified and are not redistributed.

Read more about Open-IOV →

About this wiki

This wiki previously hosted documentation from the earlier project era (2021–2023). Those pages are retained for reference under History; current documentation starts at Documentation.