Difference between revisions of "FAQ"
m (Fix repository links: point to the cgit tree URLs (git.vgpu.io/open-iov.git/tree/...)) |
m (2026-10-30 wiki refresh: goals, GSP, graphics, performance, interfaces) |
||
| Line 5: | Line 5: | ||
<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> | <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- | Status: 2026-10-30, tree <code>master @ b4930168</code>. | ||
== Project and positioning == | == Project and positioning == | ||
| Line 15: | Line 15: | ||
'''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|<code>Install-and-First-Run.md</code>]] §2). | '''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|<code>Install-and-First-Run.md</code>]] §2). | ||
'''Why is <code>nvidia-smi</code> working but my CUDA kernel not running?''' | '''Why is <code>nvidia-smi</code> 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|<code>Project-Status.md</code>]] and [[The Execution Frontier|<code>Execution-Frontier.md</code>]]. | ||
'''How fast is it?''' No published numbers yet. | '''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|<code>OpenGL.md</code>]], [[Vulkan|<code>Vulkan.md</code>]] and [[Graphics Execution|<code>Graphics-Execution.md</code>]]. | ||
'''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 == | == Compatibility == | ||
'''Will it support Windows guests?''' Yes, it is a target: same architecture, measured bring-up. [[Hardware and Software Matrix|<code>Hardware-Software-Matrix.md</code>]] lists the support ladder. | '''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, <code>nvlddmkm</code>, Direct3D) is described on [[DirectX|<code>DirectX.md</code>]]. [[Hardware and Software Matrix|<code>Hardware-Software-Matrix.md</code>]] 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. | '''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. | ||
Latest revision as of 17:06, 30 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-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 §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 and 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, Vulkan.md and 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. 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.