FAQ

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; 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 §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 and 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 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 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.

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 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.