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
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
|
# FAQ
> **What this page is.** The questions the project is asked most, answered
> honestly and with pointers to the maintained documents. Condensed from
> [`../docs/09-reference/glossary-and-faq.md`](../docs/09-reference/glossary-and-faq.md);
> the docs tree wins on disagreement.
Status: 2026-11-09, tree `master @ e342bd0f`.
## Project and positioning
**Is this a replacement for vLLM on bare metal?**
No. Continuous batching on a bare-metal host is the right answer for
centralized inference, and it stays that way. Open-IOV is for compute *inside
guests*: Linux and Windows CUDA, 3D, video, and secure edge isolation.
**Does the guest driver need to be patched?**
No, and that is a hard project rule: no guest driver patches, no host driver
patches, no firmware patches, no hypervisor patches. The guest runs the stock
NVIDIA driver, unmodified.
**Does the host driver need to be patched or replaced?**
No. In the standalone configuration the distribution driver owns the physical
GPU and Open-IOV is an independent kernel module. Building NVIDIA's OpenRM
modules from source is needed only for the native vGPU-management workflows,
not for the QEMU/emulated path
([`Install-and-First-Run.md`](Install-and-First-Run.md) §2).
**Why is `nvidia-smi` working but my CUDA kernel not running?**
It probably is running: guest CUDA kernels execute on the physical GPU and
verify — the vector-add, matrix-multiply and transformer clients are green on
fresh boots. If a specific workload fails, the known classes are: multi-megabyte
staged transfers between guest and device memory (under repair, failure modes
proven), and simultaneous CUDA guests (per-guest execution isolation is in
progress). This is the project's known status, not a misconfiguration — see
[`Project-Status.md`](Project-Status.md) and
[`Execution-Frontier.md`](Execution-Frontier.md).
**Can I run OpenGL or Vulkan applications in the guest?**
Partially, and it is an active frontier. The display/KMS stack and the X
server now run on the emulated vGPU with the stock driver: nvidia-modeset/NvKms
registers (`/dev/dri`), `glxinfo` reports OpenGL 4.6.0 with direct rendering,
the direct GL client's GR and CE channels submit and retire, and GZDoom
reaches renderer startup and `MAP01` — but currently on Mesa llvmpipe. The
guest Vulkan pipeline runs end to end (device → command buffer → fence →
readback, frames black). Rendered (non-black) frames through the NVIDIA path
are the remaining wall: the NVIDIA Vulkan ICD/forced-GLX renderer path, the X
DDX get-word/notifier completion, the DDX's 4 GB sysmem allocation (12 GB
guest workaround) and physical dispatch of the GL draws are the current gates
— see [`OpenGL.md`](OpenGL.md), [`Vulkan.md`](Vulkan.md) and
[`Graphics-Execution.md`](Graphics-Execution.md).
**How fast is it?**
No published numbers yet. Kernel launches execute on the physical engine;
what remains unmeasured is the project's own methodology — nothing ships as a
performance claim without its measurements. The first scheduled measurement
is the graphics target (60 fps sustained in one VM, no forcing).
## Compatibility
**Will it support Windows guests?**
Yes, it is a target: same architecture, measured bring-up. No Windows guest
has been booted on the emulated vGPU yet; the Windows/DirectX path (WDDM,
`nvlddmkm`, Direct3D) is described on [`DirectX.md`](DirectX.md).
[`Hardware-Software-Matrix.md`](Hardware-Software-Matrix.md) lists the
support ladder.
**Can I run several VMs on one GPU?**
That is a core design goal: one mediated device per VM, IOMMU isolation, and
explicit scheduling at the GPU's memory-management unit. Multi-tenant maturity
depends on the scheduling and isolation work tracked in the project's
known-unknowns document.
**Does it support Xen / Qubes OS Air / Argo / OpenXT?**
Designed for them. The emulation core is hypervisor-independent by
construction; the transport backends are on the roadmap. KVM/QEMU with VFIO
mdev is the reference transport today.
**What about MIG?**
MIG is a hardware partitioning mechanism; the project's scheduling policy can
use it where available. It is part of the multi-tenancy work.
**Which GPUs are supported?**
Turing TU104 is the reference platform. Other generations are targets or
experimental combinations — see
[`Hardware-Software-Matrix.md`](Hardware-Software-Matrix.md) for the exact
ladder and what each status means.
## Legal and licensing
**How is this legal / license-clean?**
Open-IOV's own code is BSD-3-Clause (GPL-2.0 for the kernel modules that link
GPL-only kernel exports); NVIDIA's software is used unmodified and is not
redistributed. The project interoperates with the interfaces rather than
relicensing anything. Details: the repository `LICENSE` and the legal
reference in `docs/09-reference/`.
**Can my company use this commercially?**
Yes, under BSD-3-Clause (kernel modules GPL-2.0), with no fee. Co-development
is welcome — see [`HAAEEP-and-Collaboration.md`](HAAEEP-and-Collaboration.md).
## Contributing
**Where do I report bugs or ask for help?**
Open an issue in the repository with a reproduction and the standard captures
(host dmesg, guest dmesg, guest `lspci -vvv`, guest driver parameters). A
reproduction plus logs is worth more than a description.
**How do I contribute support for my GPU / driver / hypervisor?**
Start from [`Hardware-Software-Matrix.md`](Hardware-Software-Matrix.md) and
the portability workflow in the repository. The deliverable is a profile plus
evidence from the project's evaluation ladder.
**How do I debug the firmware side?**
The risc-v-gsp-rm-debugger workbench runs GSP firmware in a RISC-V virtual
machine with hooks, watchpoints and recorded sessions —
[`Riscv-GSP-RM-Debugger.md`](Riscv-GSP-RM-Debugger.md).
|
