1.. _Glossary: 2 3-------- 4Glossary 5-------- 6 7This section of the manual presents brief definitions of acronyms and terms used 8by QEMU developers. 9 10Accelerator 11----------- 12 13A specific API used to accelerate execution of guest instructions. It can be 14hardware-based, through a virtualization API provided by the host OS (kvm, hvf, 15whpx, ...), or software-based (tcg). See this description of `supported 16accelerators<Accelerators>`. 17 18Board 19----- 20 21Another name for :ref:`machine`. 22 23Block 24----- 25 26Block drivers are the available `disk formats and front-ends 27<block-drivers>` available, and block devices `(see Block device section on 28options page)<sec_005finvocation>` are using them to implement disks for a 29virtual machine. 30 31CFI 32--- 33 34Control Flow Integrity is a hardening technique used to prevent exploits 35targeting QEMU by detecting unexpected branches during execution. QEMU `actively 36supports<cfi>` being compiled with CFI enabled. 37 38Device 39------ 40 41In QEMU, a device is a piece of hardware visible to the guest. Examples include 42UARTs, PCI controllers, PCI cards, VGA controllers, and many more. 43 44QEMU is able to emulate a CPU, and all the hardware interacting with it, 45including `many devices<device-emulation>`. When QEMU runs a virtual machine 46using a hardware-based accelerator, it is responsible for emulating, using 47software, all devices. 48 49EDK2 50---- 51 52EDK2, as known as `TianoCore <https://www.tianocore.org/>`_, is an open source 53implementation of UEFI standard. QEMU virtual machines that boot a UEFI firmware 54usually use EDK2. 55 56gdbstub 57------- 58 59QEMU implements a `gdb server <GDB usage>`, allowing gdb to attach to it and 60debug a running virtual machine, or a program in user-mode. This allows 61debugging the guest code that is running inside QEMU. 62 63glib2 64----- 65 66`GLib2 <https://docs.gtk.org/glib/>`_ is one of the most important libraries we 67are using through the codebase. It provides many data structures, macros, string 68and thread utilities and portable functions across different OS. It's required 69to build QEMU. 70 71Guest agent 72----------- 73 74The `QEMU Guest Agent <qemu-ga>` is a daemon intended to be run within virtual 75machines. It provides various services to help QEMU to interact with it. 76 77.. _guest: 78 79Guest 80----- 81 82Guest is the architecture of the virtual machine, which is emulated. 83See also :ref:`host`. 84 85Sometimes this is called the :ref:`target` architecture, but that term 86can be ambiguous. 87 88.. _host: 89 90Host 91---- 92 93Host is the architecture on which QEMU is running on, which is native. 94See also :ref:`guest`. 95 96Hypervisor 97---------- 98 99The formal definition of an hypervisor is a program or API than can be used to 100manage a virtual machine. QEMU is a virtualizer, that interacts with various 101hypervisors. 102 103In the context of QEMU, an hypervisor is an API, provided by the Host OS, 104allowing to execute virtual machines. Linux implementation is KVM (and supports 105Xen as well). For MacOS, it's HVF. Windows defines WHPX. And NetBSD provides 106NVMM. 107 108.. _machine: 109 110Machine 111------- 112 113QEMU's system emulation models many different types of hardware. A machine model 114(sometimes called a board model) is the model of a complete virtual system with 115RAM, one or more CPUs, and various devices. It can be selected with the option 116``-machine`` of qemu-system. Our machine models can be found on this `page 117<system-targets-ref>`. 118 119Migration 120--------- 121 122QEMU can save and restore the execution of a virtual machine between different 123host systems. This is provided by the `Migration framework<migration>`. 124 125NBD 126--- 127 128The `QEMU Network Block Device server <qemu-nbd>` is a tool that can be used to 129mount and access QEMU images, providing functionality similar to a loop device. 130 131Mailing List 132------------ 133 134This is `where <https://wiki.qemu.org/Contribute/MailingLists>`_ all the 135development happens! Changes are posted as series, that all developers can 136review and share feedback for. 137 138For reporting issues, our `GitLab 139<https://gitlab.com/qemu-project/qemu/-/issues>`_ tracker is the best place. 140 141.. _softmmu: 142 143MMU / softmmu 144------------- 145 146The Memory Management Unit is responsible for translating virtual addresses to 147physical addresses and managing memory protection. QEMU system mode is named 148"softmmu" precisely because it implements this in software, including a TLB 149(Translation lookaside buffer), for the guest virtual machine. 150 151QEMU user-mode does not implement a full software MMU, but "simply" translates 152virtual addresses by adding a specific offset, and relying on host MMU/OS 153instead. 154 155Monitor / QMP / HMP 156------------------- 157 158The `QEMU Monitor <QEMU monitor>` is a text interface which can be used to interact 159with a running virtual machine. 160 161QMP stands for QEMU Monitor Protocol and is a json based interface. 162HMP stands for Human Monitor Protocol and is a set of text commands available 163for users who prefer natural language to json. 164 165MTTCG 166----- 167 168Multiple CPU support was first implemented using a round-robin algorithm 169running on a single thread. Later on, `Multi-threaded TCG <mttcg>` was developed 170to benefit from multiple cores to speed up execution. 171 172Plugins 173------- 174 175`TCG Plugins <TCG Plugins>` is an API used to instrument guest code, in system 176and user mode. The end goal is to have a similar set of functionality compared 177to `DynamoRIO <https://dynamorio.org/>`_ or `valgrind <https://valgrind.org/>`_. 178 179One key advantage of QEMU plugins is that they can be used to perform 180architecture agnostic instrumentation. 181 182Patchew 183------- 184 185`Patchew <https://patchew.org/QEMU/>`_ is a website that tracks patches on the 186Mailing List. 187 188PR 189-- 190 191Once a series is reviewed and accepted by a subsystem maintainer, it will be 192included in a PR (Pull Request) that the project maintainer will merge into QEMU 193main branch, after running tests. 194 195The QEMU project doesn't currently expect most developers to directly submit 196pull requests. 197 198QCOW2 199----- 200 201QEMU Copy On Write is a disk format developed by QEMU. It provides transparent 202compression, automatic extension, and many other advantages over a raw image. 203 204qcow2 is the recommended format to use. 205 206QEMU 207---- 208 209`QEMU (Quick Emulator) <https://www.qemu.org/>`_ is a generic and open source 210machine emulator and virtualizer. 211 212QOM 213--- 214 215`QEMU Object Model <qom>` is an object oriented API used to define various 216devices and hardware in the QEMU codebase. 217 218Record/replay 219------------- 220 221`Record/replay <replay>` is a feature of QEMU allowing to have a deterministic 222and reproducible execution of a virtual machine. 223 224Rust 225---- 226 227`A new programming language <https://www.rust-lang.org/>`_, memory safe by 228default. There is a work in progress to integrate it in QEMU codebase for 229various subsystems. 230 231System mode 232----------- 233 234QEMU System mode provides a virtual model of an entire machine (CPU, memory and 235emulated devices) to run a guest OS. In this mode the CPU may be fully emulated, 236or it may work with a hypervisor such as KVM, Xen or Hypervisor.Framework to 237allow the guest to run directly on the host CPU. 238 239QEMU System mode is called :ref:`softmmu <softmmu>` as well. 240 241.. _target: 242 243Target 244------ 245 246The term "target" can be ambiguous. In most places in QEMU it is used as a 247synonym for :ref:`guest`. For example the code for emulating Arm CPUs is in 248``target/arm/``. However in the :ref:`TCG subsystem <tcg>` "target" refers to the 249architecture which QEMU is running on, i.e. the :ref:`host`. 250 251TCG 252--- 253 254TCG is the QEMU `Tiny Code Generator <tcg>`. It is the JIT (just-in-time) 255compiler we use to emulate a guest CPU in software. 256 257It is one of the accelerators supported by QEMU, and supports a lot of 258guest/host architectures. 259 260User mode 261--------- 262 263QEMU User mode can launch processes compiled for one CPU on another CPU. In this 264mode the CPU is always emulated. In this mode, QEMU translate system calls from 265guest to host kernel. It is available for Linux and BSD. 266 267VirtIO 268------ 269 270VirtIO is an open standard used to define and implement virtual devices with a 271minimal overhead, defining a set of data structures and hypercalls (similar to 272system calls, but targeting an hypervisor, which happens to be QEMU in our 273case). It's designed to be more efficient than emulating a real device, by 274minimizing the amount of interactions between a guest VM and its hypervisor. 275 276vhost-user 277---------- 278 279`Vhost-user <vhost_user>` is an interface used to implement VirtIO devices 280outside of QEMU itself. 281