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
118
119
120
121
122
123
124
125
126
127
128
129
130
|
# 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-14, tree `master @ 339da842`.
## 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 run on the emulated vGPU with the stock driver: nvidia-modeset/NvKms
registers (`/dev/dri`), the stock NVIDIA GLX path is fully green
(`glxinfo -B` returns 0 with OpenGL 4.6.0 direct rendering; `glxgears`
renders ~520 FPS), the 2D path is green and the DDX 3D replay executes. The
**first non-black GPU-rendered output** is proven: a pbuffer probe returns
`pixel=ff0000ff`, the off-screen path produced 500/500 non-black animated
frames per run, and videos were captured (45.4 s on 2026-11-11, 50 s on
2026-11-12). GZDoom reaches `V_Init: allocate screen` with its GL 4.6.0
context on an even modeNum. The X DDX idle-DMA/ScreenInit, USERD-latch,
re-probe, kernel-mode-spin and flip-event walls were closed (X green >10
minutes), captured GL sections now execute on the engine, and the direct-GL
submission is fully decoded: it carries no classic draw header (the work is
macro-driven; data-block blobs plus small state pushes invoking MME macros),
the recycled pushes are recovered, and the client's draw-state push opens,
captures and reaches the engine. Window and screen pixels are still the wall:
the MME macro program does not complete (the 2799-word packed program cannot
fit its <=2048-word block with the draw window, so `live_gen` never promotes
and the draw never stores; the multi-part keep-window A/B is pending), RT
routing was tested and refuted as the cause, glxgears' window is black, and X
start keeps a per-boot first-generation lottery. The guest Vulkan pipeline
runs end to end (device
→ command buffer → fence → readback) but frames are black. 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).
|
