# 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-30, tree `master @ b4930168`.

## 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 X server and GLX come up on the
emulated vGPU with the stock driver, the engine executes real GL method
streams (verbatim 3D replay plus synthesized launches), and the guest Vulkan
pipeline runs end to end (device → command buffer → fence → readback).
Rendered (non-black) frames are the remaining wall — 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).