WikiBot: Fix repository links: point to the cgit tree URLs (git.vgpu.io/open-iov.git/tree/...)

2026-10-12T04:40:08Z

Fix repository links: point to the cgit tree URLs (git.vgpu.io/open-iov.git/tree/...)

← Older revision		Revision as of 04:40, 12 October 2026
Line 3:		Line 3:
	= 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/~~blob/master~~/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-12, tree <code>master @ 2f066727</code>.		Status: 2026-10-12, tree <code>master @ 2f066727</code>.

WikiBot: Carry the site-wide About/licensing message on every page (2026-10-12)

2026-10-12T04:29:44Z

Carry the site-wide About/licensing message on every page (2026-10-12)

← Older revision		Revision as of 04:29, 12 October 2026
Line 1:		Line 1:
			{{About message}}

	= FAQ =		= FAQ =

WikiBot: Add page from tracked wiki source (2026 IA update)

2026-10-12T04:22:08Z

Add page from tracked wiki source (2026 IA update)

New page

= 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/blob/master/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>.

== 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|<code>Install-and-First-Run.md</code>]] §2).

'''Why is <code>nvidia-smi</code> working but my CUDA kernel not running?''' Because execution is the frontier, not the setup. Today, a stock guest driver probes, <code>nvidia-smi</code> 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 (<code>[wall]</code>). 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. 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 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.

'''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 and Software Matrix|<code>Hardware-Software-Matrix.md</code>]] 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 <code>LICENSE</code> and the legal reference in <code>docs/09-reference/</code>.

'''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|<code>HAAEEP-and-Collaboration.md</code>]].

== 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 <code>lspci -vvv</code>, 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 and Software Matrix|<code>Hardware-Software-Matrix.md</code>]] 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 — [[risc-v-gsp-rm-debugger|<code>Riscv-GSP-RM-Debugger.md</code>]].

FAQ - Revision history

WikiBot: Fix repository links: point to the cgit tree URLs (git.vgpu.io/open-iov.git/tree/...)

WikiBot: Carry the site-wide About/licensing message on every page (2026-10-12)

WikiBot: Add page from tracked wiki source (2026 IA update)