| .. _Glossary: | 
 |  | 
 | -------- | 
 | 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<Accelerators>`. | 
 |  | 
 | Board | 
 | ----- | 
 |  | 
 | Another name for :ref:`machine`. | 
 |  | 
 | Block | 
 | ----- | 
 |  | 
 | Block drivers are the available `disk formats and front-ends | 
 | <block-drivers>` available, and block devices `(see Block device section on | 
 | options page)<sec_005finvocation>` 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<cfi>` 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<device-emulation>`. 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 <https://www.tianocore.org/>`_, 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 <GDB usage>`, 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 <https://docs.gtk.org/glib/>`_ 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 <qemu-ga>` is a daemon intended to be run within virtual | 
 | machines. It provides various services to help QEMU to interact with it. | 
 |  | 
 | .. _guest: | 
 |  | 
 | Guest | 
 | ----- | 
 |  | 
 | Guest is the architecture of the virtual machine, which is emulated. | 
 | See also :ref:`host`. | 
 |  | 
 | Sometimes this is called the :ref:`target` architecture, but that term | 
 | can be ambiguous. | 
 |  | 
 | .. _host: | 
 |  | 
 | Host | 
 | ---- | 
 |  | 
 | Host is the architecture on which QEMU is running on, which is native. | 
 | See also :ref:`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: | 
 |  | 
 | 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 | 
 | <system-targets-ref>`. | 
 |  | 
 | Migration | 
 | --------- | 
 |  | 
 | QEMU can save and restore the execution of a virtual machine between different | 
 | host systems. This is provided by the :ref:`Migration framework<migration>`. | 
 |  | 
 | NBD | 
 | --- | 
 |  | 
 | The `QEMU Network Block Device server <qemu-nbd>` 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 <https://wiki.qemu.org/Contribute/MailingLists>`_ all the | 
 | development happens! Changes are posted as series, that all developers can | 
 | review and share feedback for. | 
 |  | 
 | For reporting issues, our `GitLab | 
 | <https://gitlab.com/qemu-project/qemu/-/issues>`_ tracker is the best place. | 
 |  | 
 | .. _softmmu: | 
 |  | 
 | 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 <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 <mttcg>` was developed | 
 | to benefit from multiple cores to speed up execution. | 
 |  | 
 | Plugins | 
 | ------- | 
 |  | 
 | `TCG 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 <https://dynamorio.org/>`_ or `valgrind <https://valgrind.org/>`_. | 
 |  | 
 | One key advantage of QEMU plugins is that they can be used to perform | 
 | architecture agnostic instrumentation. | 
 |  | 
 | Patchew | 
 | ------- | 
 |  | 
 | `Patchew <https://patchew.org/QEMU/>`_ 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) <https://www.qemu.org/>`_ is a generic and open source | 
 | machine emulator and virtualizer. | 
 |  | 
 | QOM | 
 | --- | 
 |  | 
 | :ref:`QEMU Object Model <qom>` is an object oriented API used to define | 
 | various devices and hardware in the QEMU codebase. | 
 |  | 
 | Record/replay | 
 | ------------- | 
 |  | 
 | :ref:`Record/replay <replay>` is a feature of QEMU allowing to have a | 
 | deterministic and reproducible execution of a virtual machine. | 
 |  | 
 | Rust | 
 | ---- | 
 |  | 
 | `A new programming language <https://www.rust-lang.org/>`_, 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 :ref:`softmmu <softmmu>` as well. | 
 |  | 
 | .. _target: | 
 |  | 
 | Target | 
 | ------ | 
 |  | 
 | The term "target" can be ambiguous. In most places in QEMU it is used as a | 
 | synonym for :ref:`guest`. For example the code for emulating Arm CPUs is in | 
 | ``target/arm/``. However in the :ref:`TCG subsystem <tcg>` "target" refers to the | 
 | architecture which QEMU is running on, i.e. the :ref:`host`. | 
 |  | 
 | TCG | 
 | --- | 
 |  | 
 | TCG is the QEMU `Tiny Code Generator <tcg>`. 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 <vhost_user>` is an interface used to implement VirtIO devices | 
 | outside of QEMU itself. |