Glossary - Revision history

Arthur: /* Virtual GPU (vGPU) */

2023-03-27T19:24:26Z

Virtual GPU (vGPU)

← Older revision		Revision as of 19:24, 27 March 2023
Line 22:		Line 22:

	=== Virtual GPU (vGPU) ===		=== Virtual GPU (vGPU) ===
	<blockquote>A Virtual GPU (vGPU) is a GPU which has been virtualized to represent a percentage of the total hardware resource via preemptive scheduling and/or a partition of the device's Video Random Access Memory (VRAM).</blockquote>		<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 ===		=== 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>		<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>

Arthur at 00:30, 2 March 2023

2023-03-02T00:30:13Z

← Older revision		Revision as of 00:30, 2 March 2023
Line 1:		Line 1:
			<blockquote>An absence of critical technical documentation has historically slowed growth and adoption of developer ecosystems for GPU virtualization.

			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.

			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>

	== Definitions ==		== Definitions ==

Arthur at 03:51, 13 September 2022

2022-09-13T03:51:26Z

← Older revision		Revision as of 03:51, 13 September 2022
Line 43:		Line 43:

	=== VirGL ===		=== 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>VirGL + VirtIO-GPU have provided a robust way to run graphics instructions on hardware platforms incapable of running mediated device drivers either due to artificial vendor imposed firmware limitations on commodity GPU hardware (AMD GPU-IOV Module) or due to vendor imposed driver limitations (Nvidia GRID) where it will continue to remain relevant. Unfortunately this approach incurs a substantial performance penalty compared to VFIO passthrough.		<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>

Arthur: /* Definitions */

2022-08-02T18:56:17Z

Definitions

← Older revision		Revision as of 18:56, 2 August 2022
Line 13:		Line 13:
	[[File:VFIO-Mdev Diagram.png\|thumb\|A diagram depicting VFIO Mediated Device interacting with two vGPU guests.]]		[[File:VFIO-Mdev Diagram.png\|thumb\|A diagram depicting VFIO Mediated Device interacting with two vGPU guests.]]

	=== Virtual ~~GPU~~ (vCPU) ===		=== Virtual CPU (vCPU) ===
	<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>		<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>

Arthur at 18:55, 2 August 2022

2022-08-02T18:55:44Z

← Older revision		Revision as of 18:55, 2 August 2022
Line 1:		Line 1:

	== Definitions ==		== Definitions ==
	This ~~section~~ will attempt to ~~define some~~ of ~~the~~ terms that are either related to ~~the content of this article~~ or ~~were~~ used ~~throughout this article~~ for those who may need more context.		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.

	=== VFIO ===		=== VFIO ===

Arthur: /* Virtual GPU (vGPU) */

2022-08-02T18:53:01Z

Virtual GPU (vGPU)

← Older revision		Revision as of 18:53, 2 August 2022
Line 15:		Line 15:

	=== Virtual GPU (vGPU) ===		=== Virtual GPU (vGPU) ===
	<blockquote>A Virtual GPU (vGPU) is a GPU which has been virtualized to represent a percentage of the total hardware resource via preemptive scheduling and/or a partition of the device's ~~video memory~~ (VRAM).</blockquote>		<blockquote>A Virtual GPU (vGPU) is a GPU which has been virtualized to represent a percentage of the total hardware resource via preemptive scheduling and/or a partition of the device's Video Random Access Memory (VRAM).</blockquote>
	=== IVSHMEM ===		=== 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>		<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>

Arthur: /* Definitions */

2022-08-02T18:52:31Z

Definitions

← Older revision		Revision as of 18:52, 2 August 2022
Line 11:		Line 11:
	[[File:VFIO-Mdev Diagram.png\|thumb\|A diagram depicting VFIO Mediated Device interacting with two vGPU guests.]]		[[File:VFIO-Mdev Diagram.png\|thumb\|A diagram depicting VFIO Mediated Device interacting with two vGPU guests.]]

			=== Virtual GPU (vCPU) ===
			<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>

			=== Virtual GPU (vGPU) ===
			<blockquote>A Virtual GPU (vGPU) is a GPU which has been virtualized to represent a percentage of the total hardware resource via preemptive scheduling and/or a partition of the device's video memory (VRAM).</blockquote>
	=== IVSHMEM ===		=== 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>		<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>

Arthur: Arthur moved page Introductory Concepts & Definitions to Glossary: Simplifying the page title to 'Glossary' so it can be linked from other pages to provide clarity on concepts/technical terms where needed.

2022-08-02T18:41:47Z

Arthur moved page Introductory Concepts & Definitions to Glossary: Simplifying the page title to 'Glossary' so it can be linked from other pages to provide clarity on concepts/technical terms where needed.

← Older revision	Revision as of 18:41, 2 August 2022
(No difference)

Arthur at 03:43, 17 April 2022

2022-04-17T03:43:04Z

← Older revision		Revision as of 03:43, 17 April 2022
Line 1:		Line 1:

	== Definitions ==		== Definitions ==
	~~[[File:VFIO Diagram.png\|thumb\|A diagram depicting direct VFIO passthrough of a GPU adapter.]]~~
	This section will attempt to define some of the terms that are either related to the content of this article or were used throughout this article for those who may need more context.		This section will attempt to define some of the terms that are either related to the content of this article or were used throughout this article for those who may need more context.

	=== VFIO ===		=== VFIO ===
	<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>		<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~~-Mdev~~ Diagram.png\|thumb\|A diagram depicting VFIO ~~Mediated Device interacting with two vGPU guests~~.]]		[[File:VFIO Diagram.png\|thumb\|A diagram depicting direct VFIO passthrough of a GPU adapter.]]

	=== Mdev ===		=== Mdev ===
	<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>		<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:~~IVSHMEM~~.png\|thumb\|A diagram depicting ~~an inter-vm shared memory device being used by~~ two ~~separate virtual machines~~.]]		[[File:VFIO-Mdev Diagram.png\|thumb\|A diagram depicting VFIO Mediated Device interacting with two vGPU guests.]]

	=== IVSHMEM ===		=== 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>		<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:~~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~~. ]]		[[File:IVSHMEM.png\|thumb\|A diagram depicting an inter-vm shared memory device being used by two separate virtual machines.]]

	=== KVMFR (Looking Glass) ===		=== KVMFR (Looking Glass) ===
	<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>		<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:~~NUMA Node~~.png\|thumb\|A ~~diagram depicting Non-Uniform Memory Access~~ (~~NUMA~~) ~~nodes~~.]]		[[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. ]]

	=== NUMA Node ===		=== NUMA Node ===
	<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>		<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:~~Application Binary Interface (ABI)~~.png\|thumb\|A diagram ~~contrasting API and ABI as well as their respective roles in software compatibility~~.]]		[[File:NUMA Node.png\|thumb\|A diagram depicting Non-Uniform Memory Access (NUMA) nodes.]]

	=== Application Binary Interface (ABI) ===		=== Application Binary Interface (ABI) ===
	<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>		<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:~~SR-IOV~~.png\|thumb\|A diagram ~~depicting host~~ and ~~guest interactions~~ in ~~a Single Root I/O Virtualization environment.]]~~		[[File:Application Binary Interface (ABI).png\|thumb\|A diagram contrasting API and ABI as well as their respective roles in software compatibility.]]
	~~[[File:SR-IOV-Diagram.png\|thumb\|A diagram of Intel's GVT-g (Graphics Virtualization Technology g)~~.]]

	=== SR-IOV ===		=== SR-IOV ===
	<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>		<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 ===		=== GVT-g ===
	<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>		<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>
			[[File:SR-IOV-Diagram.png\|thumb\|A diagram of Intel's GVT-g (Graphics Virtualization Technology g).]]

	=== VirGL ===		=== 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>VirGL + VirtIO-GPU have provided a robust way to run graphics instructions on hardware platforms incapable of running mediated device drivers either due to artificial vendor imposed firmware limitations on commodity GPU hardware (AMD GPU-IOV Module) or due to vendor imposed driver limitations (Nvidia GRID) where it will continue to remain relevant. Unfortunately this approach incurs a substantial performance penalty compared to VFIO passthrough.		<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>VirGL + VirtIO-GPU have provided a robust way to run graphics instructions on hardware platforms incapable of running mediated device drivers either due to artificial vendor imposed firmware limitations on commodity GPU hardware (AMD GPU-IOV Module) or due to vendor imposed driver limitations (Nvidia GRID) where it will continue to remain relevant. Unfortunately this approach incurs a substantial performance penalty compared to VFIO passthrough.

Arthur: Added additional diagram descriptions.

2021-12-18T00:59:23Z

Added additional diagram descriptions.

← Older revision		Revision as of 00:59, 18 December 2021
Line 1:		Line 1:

	== Definitions ==		== Definitions ==
	[[File:VFIO Diagram.png\|thumb]]		[[File:VFIO Diagram.png\|thumb\|A diagram depicting direct VFIO passthrough of a GPU adapter.]]
	This section will attempt to define some of the terms that are either related to the content of this article or were used throughout this article for those who may need more context.		This section will attempt to define some of the terms that are either related to the content of this article or were used throughout this article for those who may need more context.

	=== VFIO ===		=== VFIO ===
	<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>		<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-Mdev Diagram.png\|thumb]]		[[File:VFIO-Mdev Diagram.png\|thumb\|A diagram depicting VFIO Mediated Device interacting with two vGPU guests.]]

	=== Mdev ===		=== Mdev ===
	<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>		<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:IVSHMEM.png\|thumb]]		[[File:IVSHMEM.png\|thumb\|A diagram depicting an inter-vm shared memory device being used by two separate virtual machines.]]

	=== IVSHMEM ===		=== 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>		<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:KVMFR Looking Glass.png\|thumb]]		[[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. ]]

	=== KVMFR (Looking Glass) ===		=== KVMFR (Looking Glass) ===
	<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>		<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:NUMA Node.png\|thumb]]		[[File:NUMA Node.png\|thumb\|A diagram depicting Non-Uniform Memory Access (NUMA) nodes.]]

	=== NUMA Node ===		=== NUMA Node ===
	<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>		<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:Application Binary Interface (ABI).png\|thumb]]		[[File:Application Binary Interface (ABI).png\|thumb\|A diagram contrasting API and ABI as well as their respective roles in software compatibility.]]

	=== Application Binary Interface (ABI) ===		=== Application Binary Interface (ABI) ===
	<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>		<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:SR-IOV.png\|thumb]]		[[File:SR-IOV.png\|thumb\|A diagram depicting host and guest interactions in a Single Root I/O Virtualization environment.]]
	[[File:SR-IOV-Diagram.png\|thumb\|A diagram of Intel's GVT-g (Graphics Virtualization Technology g).]]		[[File:SR-IOV-Diagram.png\|thumb\|A diagram of Intel's GVT-g (Graphics Virtualization Technology g).]]