Difference between revisions of "FAQ"
(Add page from tracked wiki source (2026 IA update)) |
m (Fix repository links: point to the cgit tree URLs (git.vgpu.io/open-iov.git/tree/...)) |
||
| (One intermediate revision by the same user not shown) | |||
| Line 1: | Line 1: | ||
{{About message}} | |||
= FAQ = | = FAQ = | ||
<blockquote>'''What this page is.''' The questions the project is asked most, answered honestly and with pointers to the maintained documents. Condensed from [https://git.vgpu.io/open-iov/ | <blockquote>'''What this page is.''' The questions the project is asked most, answered honestly and with pointers to the maintained documents. Condensed from [https://git.vgpu.io/open-iov.git/tree/docs/09-reference/glossary-and-faq.md <code>../docs/09-reference/glossary-and-faq.md</code>]; the docs tree wins on disagreement.</blockquote> | ||
Status: 2026-10-12, tree <code>master @ 2f066727</code>. | Status: 2026-10-12, tree <code>master @ 2f066727</code>. | ||
Latest revision as of 04:40, 12 October 2026
An absence of critical technical documentation has historically slowed growth and adoption of developer ecosystems for GPU virtualization.
This CC-BY-4.0 licensed content can either be used with attribution, or used as inspiration for new documentation, created by GPU vendors for public commercial distribution as developer documentation.
Where possible, this documentation will clearly label dates and versions of observed-but-not-guaranteed behaviour vs. vendor-documented stable interfaces/behaviour with guarantees of forward or backward compatibility.
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.