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
|
# 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-10-12, tree `master @ 2f066727`.
## 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?**
Because execution is the frontier, not the setup. Today, a stock guest driver
probes, `nvidia-smi` works, device enumeration works, and the full CUDA
**driver-API** path (context creation, allocation, copies, free, destroy)
completes; a guest **kernel launch** is forwarded to the physical engine queue
but the engine does not yet execute the forwarded launch descriptor
(`[wall]`). This is the project's known status, not a misconfiguration — see
[`Project-Status.md`](Project-Status.md) and
[`Execution-Frontier.md`](Execution-Frontier.md).
**How fast is it?**
No published numbers yet. Copy-engine-class forwarding and its completion and
fault relay are implemented (default off) and GR execution is the open
frontier; even the initialization path has not yet been measured under the
project's methodology. Any performance claim will ship together with its
methodology and measurements.
## Compatibility
**Will it support Windows guests?**
Yes, it is a target: same architecture, measured bring-up.
[`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).
|
