Glossary

This section of the manual presents brief definitions of acronyms and terms used by QEMU developers.

Accelerator

A specific API used to accelerate execution of guest instructions. It can be hardware-based, through a virtualization API provided by the host OS (kvm, hvf, whpx, …), or software-based (tcg). See this description of supported accelerators.

Board

Another name for Machine.

Block

Block drivers are the available disk formats and front-ends available, and block devices (see Block device section on options page) are using them to implement disks for a virtual machine.

CFI

Control Flow Integrity is a hardening technique used to prevent exploits targeting QEMU by detecting unexpected branches during execution. QEMU actively supports being compiled with CFI enabled.

Device

In QEMU, a device is a piece of hardware visible to the guest. Examples include UARTs, PCI controllers, PCI cards, VGA controllers, and many more.

QEMU is able to emulate a CPU, and all the hardware interacting with it, including many devices. When QEMU runs a virtual machine using a hardware-based accelerator, it is responsible for emulating, using software, all devices.

EDK2

EDK2, as known as TianoCore, is an open source implementation of UEFI standard. QEMU virtual machines that boot a UEFI firmware usually use EDK2.

gdbstub

QEMU implements a gdb server, allowing gdb to attach to it and debug a running virtual machine, or a program in user-mode. This allows debugging the guest code that is running inside QEMU.

glib2

GLib2 is one of the most important libraries we are using through the codebase. It provides many data structures, macros, string and thread utilities and portable functions across different OS. It’s required to build QEMU.

Guest agent

The QEMU Guest Agent is a daemon intended to be run within virtual machines. It provides various services to help QEMU to interact with it.

Guest

Guest is the architecture of the virtual machine, which is emulated. See also Host.

Sometimes this is called the Target architecture, but that term can be ambiguous.

Host

Host is the architecture on which QEMU is running on, which is native. See also Guest.

Hypervisor

The formal definition of an hypervisor is a program or API than can be used to manage a virtual machine. QEMU is a virtualizer, that interacts with various hypervisors.

In the context of QEMU, an hypervisor is an API, provided by the Host OS, allowing to execute virtual machines. Linux implementation is KVM (and supports Xen as well). For MacOS, it’s HVF. Windows defines WHPX. And NetBSD provides NVMM.

Machine

QEMU’s system emulation models many different types of hardware. A machine model (sometimes called a board model) is the model of a complete virtual system with RAM, one or more CPUs, and various devices. It can be selected with the option -machine of qemu-system. Our machine models can be found on this page.

Migration

QEMU can save and restore the execution of a virtual machine between different host systems. This is provided by the Migration framework.

NBD

The QEMU Network Block Device server is a tool that can be used to mount and access QEMU images, providing functionality similar to a loop device.

Mailing List

This is where all the development happens! Changes are posted as series, that all developers can review and share feedback for.

For reporting issues, our GitLab tracker is the best place.

MMU / softmmu

The Memory Management Unit is responsible for translating virtual addresses to physical addresses and managing memory protection. QEMU system mode is named “softmmu” precisely because it implements this in software, including a TLB (Translation lookaside buffer), for the guest virtual machine.

QEMU user-mode does not implement a full software MMU, but “simply” translates virtual addresses by adding a specific offset, and relying on host MMU/OS instead.

Monitor / QMP / HMP

The QEMU Monitor is a text interface which can be used to interact with a running virtual machine.

QMP stands for QEMU Monitor Protocol and is a json based interface. HMP stands for Human Monitor Protocol and is a set of text commands available for users who prefer natural language to json.

MTTCG

Multiple CPU support was first implemented using a round-robin algorithm running on a single thread. Later on, Multi-threaded TCG was developed to benefit from multiple cores to speed up execution.

Plugins

TCG Plugins is an API used to instrument guest code, in system and user mode. The end goal is to have a similar set of functionality compared to DynamoRIO or valgrind.

One key advantage of QEMU plugins is that they can be used to perform architecture agnostic instrumentation.

Patchew

Patchew is a website that tracks patches on the Mailing List.

PR

Once a series is reviewed and accepted by a subsystem maintainer, it will be included in a PR (Pull Request) that the project maintainer will merge into QEMU main branch, after running tests.

The QEMU project doesn’t currently expect most developers to directly submit pull requests.

QCOW2

QEMU Copy On Write is a disk format developed by QEMU. It provides transparent compression, automatic extension, and many other advantages over a raw image.

qcow2 is the recommended format to use.

QEMU

QEMU (Quick Emulator) is a generic and open source machine emulator and virtualizer.

QOM

QEMU Object Model is an object oriented API used to define various devices and hardware in the QEMU codebase.

Record/replay

Record/replay is a feature of QEMU allowing to have a deterministic and reproducible execution of a virtual machine.

Rust

A new programming language, memory safe by default. There is a work in progress to integrate it in QEMU codebase for various subsystems.

System mode

QEMU System mode provides a virtual model of an entire machine (CPU, memory and emulated devices) to run a guest OS. In this mode the CPU may be fully emulated, or it may work with a hypervisor such as KVM, Xen or Hypervisor.Framework to allow the guest to run directly on the host CPU.

QEMU System mode is called softmmu as well.

Target

The term “target” can be ambiguous. In most places in QEMU it is used as a synonym for Guest. For example the code for emulating Arm CPUs is in target/arm/. However in the TCG subsystem “target” refers to the architecture which QEMU is running on, i.e. the Host.

TCG

TCG is the QEMU Tiny Code Generator. It is the JIT (just-in-time) compiler we use to emulate a guest CPU in software.

It is one of the accelerators supported by QEMU, and supports a lot of guest/host architectures.

User mode

QEMU User mode can launch processes compiled for one CPU on another CPU. In this mode the CPU is always emulated. In this mode, QEMU translate system calls from guest to host kernel. It is available for Linux and BSD.

VirtIO

VirtIO is an open standard used to define and implement virtual devices with a minimal overhead, defining a set of data structures and hypercalls (similar to system calls, but targeting an hypervisor, which happens to be QEMU in our case). It’s designed to be more efficient than emulating a real device, by minimizing the amount of interactions between a guest VM and its hypervisor.

vhost-user

Vhost-user is an interface used to implement VirtIO devices outside of QEMU itself.