# Glossary and FAQ

## Glossary

| Term | Meaning |
|---|---|
| **AMAPlib** | NVIDIA's shared "address mapping" library: swizzling, bank/channel mapping, aperture rules. Studied for page-table and memory-layout semantics. |
| **BAR0 / BAR1 / BAR3** | PCI BAR windows of the GPU: register interface (16 MB), VRAM aperture (256 MB), instance/PRAMIN window. |
| **CE** | Copy Engine: DMA engine; also used for UVM's internal work. |
| **CUDASW** | The family of NVIDIA user-space software that sits between applications and the driver: `libcuda`, `libcudart`, JIT compiler, fatbinary loader, and friends. |
| **Doorbell** | A register/memory location a driver writes to signal "new work is available" for a channel or queue. |
| **Engine type** | Numeric identifier for an execution engine (`GR = 0x1`, `COPY0 = 0x9`, ...). |
| **FWSEC** | Firmware security processor stage of the GSP boot sequence. |
| **GNND / GB10** | NVIDIA "Grace-Blackwell" systems-on-chip used in DGX Spark and Surface-class laptops; explicit portability targets. |
| **GPFIFO** | GPU FIFO: a ring of entries, each pointing to a push buffer for a channel. |
| **GR** | The graphics/compute engine that executes shaders (graphics pipelines and CUDA kernels). |
| **GSP** | GPU System Processor: the embedded RISC-V (RV64IMAC) that runs firmware containing the Resource Manager. |
| **GSP-RM** | The Resource Manager running on the GSP ("self-hosted RM"). |
| **GMMU** | GPU Memory Management Unit: page tables, TLB, fault handling. |
| **HAL** | Hardware Abstraction Layer: per-generation functions that program registers and formats. |
| **mdev** | Mediated device: the kernel mechanism that turns a physical device into virtual instances (VFIO). |
| **MSGQ** | The GSP message queue transport: shared-memory element rings with a page table, plus doorbells. |
| **PBDMA** | Push-buffer DMA engine in the host scheduler that fetches and executes push buffers. |
| **PDB** | Page Directory Base: root of a GPU page table. |
| **PDE / PTE** | Page-directory entry / page-table entry. |
| **Push buffer** | A stream of method calls (engine commands) submitted via a GPFIFO. |
| **RMCore** | The RM's object system: classes, handles, parents, methods. |
| **RM / RM API** | NVIDIA's Resource Manager and the API used to allocate objects and issue controls. |
| **resserv / resource server** | The RM component that owns allocation authority, privileges and lifetimes. |
| **Runlist** | The scheduler's list of channels eligible to run. |
| **SEC2** | Secure copy engine used by UVM for protected operations. |
| **Semaphore / tracker** | Memory location written by the GPU to signal progress; UVM's tracker waits on it. |
| **SRIOV / VF** | Single-root I/O virtualization / virtual functions (hardware partitioning). |
| **TSG** | Time-Slice Group: channels sharing a scheduling slot. |
| **USERD** | Per-channel control block in VRAM: PUT/GET pointers and control state. |
| **UVM** | NVIDIA's unified memory module: VA spaces, page trees, faults, channel manager. |
| **VA / PA / GPA / IOVA** | Virtual address / physical address / guest physical address / I/O virtual address. |
| **vidmem / sysmem / aperture** | GPU local memory / system memory / the way an address is qualified (`ADDR_FBMEM = 2`, `ADDR_SYSMEM = 1`). |
| **VGX version** | The version the guest announces during RPC negotiation; selects message layouts. |
| **vGPU** | Virtual GPU: this project's device. |
| **WPR** | Write-Protected Region: VRAM area reserved for firmware. |

## FAQ

**Is this a replacement for vLLM on bare metal?**
No. Continuous batching on bare-metal hosts is the right answer for centralized
inference. Open-IOV is for compute *inside guests*: Windows/Linux CUDA, 3D,
video, and secure edge isolation. See the orientation docs.

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

**Does it work with the distribution's NVIDIA driver on the host?**
Yes — in the standalone configuration the distribution driver owns the physical
GPU and Open-IOV is an independent module. Building NVIDIA's OpenRM modules from
source is only needed for the native-vGPU-management workflows.

**Why is `nvidia-smi` working but CUDA not?**
Because CUDA requires *execution*: kernels must run on real hardware. The
current state runs the entire initialization path (including UVM's start-up)
but stops short of executing engine work. See the known-knowns document for
the exact status and plan.

**How is this legal / license-clean?**
Open-IOV is BSD-3-Clause (GPL-2.0 for kernel modules that link GPL-only kernel
exports); we interoperate with unmodified NVIDIA software rather than
relicensing it. See the legal document.

**Will it support Windows guests?**
Yes, it is a target: same architecture, measured bring-up. See the portability
matrix.

**Can I run several VMs on one GPU?**
Yes — that is a core design goal (per-VM mdev, IOMMU isolation, explicit
scheduling). Multi-tenant maturity depends on the scheduling/isolation work in
the known-unknowns list.

**Does it support Xen / Qubes OS Air / Argo / OpenXT?**
Designed for them; the transport backends are on the roadmap. The emulation
core is hypervisor-independent by construction.

**What about MIG?**
MIG is a hardware partitioning mechanism; Open-IOV's scheduling policy can use
it where available. It is part of the multi-tenancy work.

**How fast is it?**
Initialization currently completes in the same order of magnitude as native;
execution forwarding is not implemented yet. Performance claims follow the
published methodology in the operations docs.

**Where do I report bugs or ask for help?**
Open an issue with the standard captures listed in the debugging document. A
reproduction plus logs is worth more than a description.

**Can my company use this commercially?**
Yes, under BSD-3-Clause (kernel modules GPL-2.0), with no fee. We also welcome
co-development; see the ecosystem document.

**How do I contribute support for my GPU/driver/hypervisor?**
Follow the "adding a new combination" workflows in the portability and
maintenance docs; the deliverable is a profile plus evidence from the
evaluation ladder.