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