Difference between revisions of "Glossary"

From Open-IOV
Jump to navigation Jump to search
m (Fix repository links: point to the cgit tree URLs)
 
(3 intermediate revisions by the same user not shown)
Line 1: Line 1:
<blockquote>An absence of critical technical documentation has historically slowed growth and adoption of developer ecosystems for GPU virtualization.
{{About message}}


This [https://creativecommons.org/licenses/by/4.0/ 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.
= Glossary =


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.</blockquote>
<blockquote>'''What this page is.''' The terms used across this wiki, the project's documents and its logs. 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. For questions, see [[FAQ|<code>FAQ.md</code>]].</blockquote>


== Definitions ==
Status: 2026-10-12, tree <code>master @ 2f066727</code>.
This article will attempt to provide a glossary of common terms that are either related to/or often used in connection with virtualization for those who may need more context.


If you have suggestions on how to improve the glossary you can [https://openmdev.io/index.php/Main_Page#Getting_Started_Contributing_to_OpenMdev.io '''contribute'''] or join our [https://discord.gg/Rb9K9DYxKK '''community discussion thread'''] to make suggestions.
== GPU, driver and virtualization ==


=== VFIO ===
{| class="wikitable"
<blockquote>Kernel.org defines VFIO or Virtual Function Input Output as '''"an IOMMU/device agnostic framework for exposing direct device access to userspace, in a secure, IOMMU protected environment." [https://www.kernel.org/doc/Documentation/vfio.txt <nowiki>[1]</nowiki>]'''</blockquote>
|-
[[File:VFIO Diagram.png|thumb|A diagram depicting direct VFIO passthrough of a GPU adapter.]]
! Term
! Meaning
|-
| '''BAR0 / BAR1 / BAR3'''
| PCI BAR windows of the GPU: register interface (16 MB), VRAM aperture (256 MB), instance/PRAMIN window.
|-
| '''CUDASW'''
| The family of NVIDIA user-space software between applications and the driver: <code>libcuda</code>, <code>libcudart</code>, the JIT compiler, the fatbinary loader, and friends.
|-
| '''Doorbell'''
| A register or memory location a driver writes to signal "new work is available" for a channel or queue.
|-
| '''mdev'''
| Mediated device: the kernel mechanism that turns a physical device into virtual instances (VFIO).
|-
| '''vGPU'''
| Virtual GPU: the device this project presents to a guest.
|-
| '''SRIOV / VF'''
| Single-root I/O virtualization / virtual functions (hardware partitioning).
|-
| '''IOMMU / SMMU'''
| Platform DMA translation and isolation (Intel VT-d / AMD-Vi / ARM SMMU).
|}


=== Mdev ===
== GSP, firmware and the RM ==
<blockquote>Kernel.org defines Virtual Function I/O (VFIO) Mediated devices as: '''"an IOMMU/device-agnostic framework for exposing direct device access to user space in a secure, IOMMU-protected environment... mediated core driver provides a common interface for mediated device management that can be used by drivers of different devices." [https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git/tree/Documentation/driver-api/vfio-mediated-device.rst?h=driver-core-next&id=7de3697e9cbd4bd3d62bafa249d57990e1b8f294 <nowiki>[2]</nowiki>]'''</blockquote>
[[File:VFIO-Mdev Diagram.png|thumb|A diagram depicting VFIO Mediated Device interacting with two vGPU guests.]]


=== Virtual CPU (vCPU) ===
{| class="wikitable"
<blockquote>A Virtual CPU (vCPU) is a CPU which has been virtualized to represent a percentage of the total hardware resource via preemptive scheduling.</blockquote>
|-
! Term
! Meaning
|-
| '''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 (the "self-hosted RM").
|-
| '''RM / RM API'''
| NVIDIA's Resource Manager and the API used to allocate objects and issue controls.
|-
| '''RMCore'''
| The RM's object system: classes, handles, parents, methods.
|-
| '''resserv / resource server'''
| The RM component that owns allocation authority, privileges and lifetimes.
|-
| '''FWSEC'''
| Firmware security processor stage of the GSP boot sequence.
|-
| '''WPR'''
| Write-Protected Region: the VRAM area reserved for firmware.
|-
| '''MSGQ'''
| The GSP message-queue transport: shared-memory element rings with a page table, plus doorbells.
|-
| '''VGX version'''
| The version the guest announces during RPC negotiation; it selects message layouts.
|-
| '''Reply fidelity'''
| How completely an emulated reply matches what real hardware returns, as a ladder: status-only → coherent zeroed params → coherent values for consumed fields → exact values.
|}


=== Virtual GPU (vGPU) ===
== Execution engines and memory ==
<blockquote>A Virtual GPU (vGPU) is a GPU which has been virtualized to represent a percentage of the total hardware resource via preemptive scheduling or thread pinning (to [https://www.intel.com/content/www/us/en/docs/oneapi/optimization-guide-gpu/2023-0/intel-iris-xe-gpu-architecture.html EUs], or [https://www.nvidia.com/content/PDF/nvidia-ampere-ga-102-gpu-architecture-whitepaper-v2.pdf SMs]) and/or a partition of the device's Video Random Access Memory (VRAM).</blockquote>
=== IVSHMEM ===
<blockquote>According to QEMU's GitHub repo: '''"The Inter-VM shared memory device (ivshmem) is designed to share a memory region between multiple QEMU processes running different guests and the host.  In order for all guests to be able to pick up the shared memory area, it is modeled by QEMU as a PCI device exposing said memory to the guest as a PCI BAR."''' '''[https://github.com/qemu/qemu/blob/master/docs/specs/ivshmem-spec.txt <nowiki>[3]</nowiki>]'''</blockquote>
[[File:IVSHMEM.png|thumb|A diagram depicting an inter-vm shared memory device being used by two separate virtual machines.]]


=== KVMFR (Looking Glass) ===
{| class="wikitable"
<blockquote>looking-glass.io defines Looking Glass as: '''"an open source application that allows the use of a KVM (Kernel-based Virtual Machine) configured for VGA PCI Pass-through without an attached physical monitor, keyboard or mouse."''' '''[https://looking-glass.io/ <nowiki>[4]</nowiki>]'''</blockquote>
|-
[[File:KVMFR Looking Glass.png|thumb|A image posted by Gnif (Creator of the Looking Glass project) to a changelog thread on the Level1techs forum - an active community of VFIO users. ]]
! Term
! Meaning
|-
| '''CE'''
| Copy Engine: a DMA engine; also used for UVM's internal work.
|-
| '''GR'''
| The graphics/compute engine that executes shaders (graphics pipelines and CUDA kernels).
|-
| '''SEC2'''
| Secure copy engine used by UVM for protected operations.
|-
| '''GPFIFO'''
| GPU FIFO: a ring of entries, each pointing to a push buffer for a channel.
|-
| '''Push buffer'''
| A stream of method calls (engine commands) submitted via a GPFIFO.
|-
| '''PBDMA'''
| The push-buffer DMA engine in the host scheduler that fetches and executes push buffers.
|-
| '''QMD'''
| Queue Meta Data: the per-launch descriptor a GR channel reads to execute a kernel grid.
|-
| '''USERD'''
| Per-channel control block in VRAM: PUT/GET pointers and control state.
|-
| '''Runlist'''
| The scheduler's list of channels eligible to run.
|-
| '''TSG'''
| Time-Slice Group: channels sharing a scheduling slot.
|-
| '''Engine record / engine list'''
| The per-engine descriptors (kind, instance, class, client type) the driver walks after <code>GPU_GET_ENGINES</code>; each must be self-consistent or the driver rewrites the following allocation.
|-
| '''GMMU'''
| GPU Memory Management Unit: page tables, TLB, fault handling.
|-
| '''PDB'''
| Page Directory Base: root of a GPU page table.
|-
| '''PDE / PTE'''
| Page-directory entry / page-table entry.
|-
| '''UVM'''
| NVIDIA's unified memory module: VA spaces, page trees, faults, channel manager ([[UVM in the Guest|<code>UVM-in-the-Guest.md</code>]]).
|-
| '''VA / PA / GPA / IOVA'''
| Virtual address / physical address / guest physical address / I/O virtual address.
|-
| '''vidmem / sysmem / aperture'''
| GPU local memory / system memory / how an address is qualified.
|-
| '''Semaphore / tracker'''
| A memory location written by the GPU to signal progress; UVM's tracker waits on it.
|-
| '''AMAPlib'''
| NVIDIA's shared "address mapping" library: swizzling, bank/channel mapping, aperture rules.
|-
| '''HAL'''
| Hardware abstraction layer: per-generation functions that program registers and formats.
|-
| '''Class list (classDB)'''
| The RM classes reported as supported; engine queries are filtered against it, so the class list, engine list and capability controls must agree.
|}


=== NUMA Node ===
== Method and tooling ==
<blockquote>Infogalactic defines NUMA as: '''"''Non-uniform memory access (NUMA) is a'' computer memory design used in multiprocessing, where the memory access time depends on the memory location relative to the processor. Under NUMA, a processor can access its own local memory faster than non-local memory (memory local to another processor or memory shared between processors)." [https://infogalactic.com/info/Non-uniform_memory_access <nowiki>[5]</nowiki>]'''</blockquote>
[[File:NUMA Node.png|thumb|A diagram depicting Non-Uniform Memory Access (NUMA) nodes.]]


=== Application Binary Interface (ABI) ===
{| class="wikitable"
<blockquote>Infogalactic defines an ABI as '''"the interface between two program modules, one of which is often a library or operating system, at the level of machine code."''' '''[https://infogalactic.com/info/Application_binary_interface <nowiki>[6]</nowiki>]'''</blockquote>
|-
[[File:Application Binary Interface (ABI).png|thumb|A diagram contrasting API and ABI as well as their respective roles in software compatibility.]]
! Term
! Meaning
|-
| '''Host oracle / A-B harness'''
| The same query or deterministic workload run against a bare-metal host driver and inside the guest, then diffed — the reference for what the guest should have seen.
|-
| '''File virtual address (<code>libcuda+0x...</code>)'''
| An address relative to the start of a shared object file, as distinct from a runtime mapping or a disassembler program address.
|-
| '''Session (risc-v-gsp-rm-debugger)'''
| A recorded run of the firmware workbench — the unit of evidence ([[risc-v-gsp-rm-debugger|<code>Riscv-GSP-RM-Debugger.md</code>]]).
|}


=== SR-IOV ===
== Related pages ==
<blockquote>docs.microsoft.com defines SR-IOV as '''"The single root I/O virtualization (SR-IOV) interface is an extension to the PCI Express (PCIe) specification. SR-IOV allows a device, such as a network adapter, to separate access to its resources among various PCIe hardware functions." [https://archive.is/FcDoK <nowiki>[7]</nowiki>]'''</blockquote>
[[File:SR-IOV.png|thumb|A diagram depicting host and guest interactions in a Single Root I/O Virtualization environment.]]


=== GVT-g ===
* [[FAQ|<code>FAQ.md</code>]]
<blockquote>wiki.archlinux.org defines Intel GVT-g as '''"a technology that provides mediated device passthrough for Intel GPUs (Broadwell and newer). It can be used to virtualize the GPU for multiple guest virtual machines, effectively providing near-native graphics performance in the virtual machine and still letting your host use the virtualized GPU normally." [https://wiki.archlinux.org/title/Intel_GVT-g <nowiki>[8]</nowiki>]'''</blockquote>
* [[System Overview|<code>System-Overview.md</code>]]
[[File:SR-IOV-Diagram.png|thumb|A diagram of Intel's GVT-g (Graphics Virtualization Technology g).]]
* [[GSP and GSP-RM|<code>GSP-and-GSP-RM.md</code>]]
 
* [[Introduction to GMMU|<code>Introduction-to-GMMU.md</code>]]
=== VirGL ===
<blockquote>[[File:Virgl.png|thumb|A diagram depicting GPU instruction redirects to a single host graphics driver.]]lwn.net defines Virgl as: '''"a way for guests running in a virtual machine (VM) to access the host GPU using OpenGL and other APIs... The virgl stack consists of an application running in the guest that sends OpenGL to the Mesa virgl driver, which uses the virtio-gpu driver in the guest kernel to communicate with QEMU on the host."''' '''[https://lwn.net/Articles/767970/ <nowiki>[9]</nowiki>]'''</blockquote>

Latest revision as of 04:41, 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.

Glossary

What this page is. The terms used across this wiki, the project's documents and its logs. Condensed from ../docs/09-reference/glossary-and-faq.md; the docs tree wins on disagreement. For questions, see FAQ.md.

Status: 2026-10-12, tree master @ 2f066727.

GPU, driver and virtualization

Term Meaning
BAR0 / BAR1 / BAR3 PCI BAR windows of the GPU: register interface (16 MB), VRAM aperture (256 MB), instance/PRAMIN window.
CUDASW The family of NVIDIA user-space software between applications and the driver: libcuda, libcudart, the JIT compiler, the fatbinary loader, and friends.
Doorbell A register or memory location a driver writes to signal "new work is available" for a channel or queue.
mdev Mediated device: the kernel mechanism that turns a physical device into virtual instances (VFIO).
vGPU Virtual GPU: the device this project presents to a guest.
SRIOV / VF Single-root I/O virtualization / virtual functions (hardware partitioning).
IOMMU / SMMU Platform DMA translation and isolation (Intel VT-d / AMD-Vi / ARM SMMU).

GSP, firmware and the RM

Term Meaning
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 (the "self-hosted RM").
RM / RM API NVIDIA's Resource Manager and the API used to allocate objects and issue controls.
RMCore The RM's object system: classes, handles, parents, methods.
resserv / resource server The RM component that owns allocation authority, privileges and lifetimes.
FWSEC Firmware security processor stage of the GSP boot sequence.
WPR Write-Protected Region: the VRAM area reserved for firmware.
MSGQ The GSP message-queue transport: shared-memory element rings with a page table, plus doorbells.
VGX version The version the guest announces during RPC negotiation; it selects message layouts.
Reply fidelity How completely an emulated reply matches what real hardware returns, as a ladder: status-only → coherent zeroed params → coherent values for consumed fields → exact values.

Execution engines and memory

Term Meaning
CE Copy Engine: a DMA engine; also used for UVM's internal work.
GR The graphics/compute engine that executes shaders (graphics pipelines and CUDA kernels).
SEC2 Secure copy engine used by UVM for protected operations.
GPFIFO GPU FIFO: a ring of entries, each pointing to a push buffer for a channel.
Push buffer A stream of method calls (engine commands) submitted via a GPFIFO.
PBDMA The push-buffer DMA engine in the host scheduler that fetches and executes push buffers.
QMD Queue Meta Data: the per-launch descriptor a GR channel reads to execute a kernel grid.
USERD Per-channel control block in VRAM: PUT/GET pointers and control state.
Runlist The scheduler's list of channels eligible to run.
TSG Time-Slice Group: channels sharing a scheduling slot.
Engine record / engine list The per-engine descriptors (kind, instance, class, client type) the driver walks after GPU_GET_ENGINES; each must be self-consistent or the driver rewrites the following allocation.
GMMU GPU Memory Management Unit: page tables, TLB, fault handling.
PDB Page Directory Base: root of a GPU page table.
PDE / PTE Page-directory entry / page-table entry.
UVM NVIDIA's unified memory module: VA spaces, page trees, faults, channel manager (UVM-in-the-Guest.md).
VA / PA / GPA / IOVA Virtual address / physical address / guest physical address / I/O virtual address.
vidmem / sysmem / aperture GPU local memory / system memory / how an address is qualified.
Semaphore / tracker A memory location written by the GPU to signal progress; UVM's tracker waits on it.
AMAPlib NVIDIA's shared "address mapping" library: swizzling, bank/channel mapping, aperture rules.
HAL Hardware abstraction layer: per-generation functions that program registers and formats.
Class list (classDB) The RM classes reported as supported; engine queries are filtered against it, so the class list, engine list and capability controls must agree.

Method and tooling

Term Meaning
Host oracle / A-B harness The same query or deterministic workload run against a bare-metal host driver and inside the guest, then diffed — the reference for what the guest should have seen.
File virtual address (libcuda+0x...) An address relative to the start of a shared object file, as distinct from a runtime mapping or a disassembler program address.
Session (risc-v-gsp-rm-debugger) A recorded run of the firmware workbench — the unit of evidence (Riscv-GSP-RM-Debugger.md).

Related pages

Retrieved from "https://open-iov.org/index.php?title=Glossary&oldid=23988"