path: root/wiki/FAQ.md

# 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 @ bb802909`.

## 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 the GSP
event-IRQ fix completes swaps. X is green on attempt 1, the guest's **real GL
draws forward and execute on the physical GPU** (`work_gr backend_ok=5-7`,
`backend_timeout=0`), and the 2D path is green end-to-end, but the frames are
black: the replayed draw writes 0 pages because the beef GR ring does not
resolve deterministically, the fixed-CB image's `0x80` MVP block is zero, and
the render-target bind is unconfirmed. The guest Vulkan pipeline runs end to
end (device → command buffer → fence → readback, frames black). These three
plus the DDX's 4 GB sysmem allocation (12 GB guest workaround) 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).