1 files changed, 102 insertions, 0 deletions
diff --git a/wiki/FAQ.md b/wiki/FAQ.md
new file mode 100644
index 0000000..9472740
--- /dev/null
+++ b/wiki/FAQ.md
@@ -0,0 +1,102 @@
+# 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-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`](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`](Project-Status.md) and
+[`Execution-Frontier.md`](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`](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).