|
| 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, ...), 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 implementation is KVM (and supports |
| 105 | +Xen as well). For MacOS, it's HVF. Windows defines WHPX. And NetBSD provides |
| 106 | +NVMM. |
| 107 | + |
| 108 | +.. _machine: |
| 109 | + |
| 110 | +Machine |
| 111 | +------- |
| 112 | + |
| 113 | +QEMU'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 |
| 115 | +RAM, 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 | + |
| 119 | +Migration |
| 120 | +--------- |
| 121 | + |
| 122 | +QEMU can save and restore the execution of a virtual machine between different |
| 123 | +host systems. This is provided by the `Migration framework<migration>`. |
| 124 | + |
| 125 | +NBD |
| 126 | +--- |
| 127 | + |
| 128 | +The `QEMU Network Block Device server <qemu-nbd>` is a tool that can be used to |
| 129 | +mount and access QEMU images, providing functionality similar to a loop device. |
| 130 | + |
| 131 | +Mailing List |
| 132 | +------------ |
| 133 | + |
| 134 | +This is `where <https://wiki.qemu.org/Contribute/MailingLists>`_ all the |
| 135 | +development happens! Changes are posted as series, that all developers can |
| 136 | +review and share feedback for. |
| 137 | + |
| 138 | +For reporting issues, our `GitLab |
| 139 | +<https://gitlab.com/qemu-project/qemu/-/issues>`_ tracker is the best place. |
| 140 | + |
| 141 | +.. _softmmu: |
| 142 | + |
| 143 | +MMU / softmmu |
| 144 | +------------- |
| 145 | + |
| 146 | +The Memory Management Unit is responsible for translating virtual addresses to |
| 147 | +physical 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 | + |
| 151 | +QEMU user-mode does not implement a full software MMU, but "simply" translates |
| 152 | +virtual addresses by adding a specific offset, and relying on host MMU/OS |
| 153 | +instead. |
| 154 | + |
| 155 | +Monitor / QMP / HMP |
| 156 | +------------------- |
| 157 | + |
| 158 | +The `QEMU Monitor <QEMU monitor>` is a text interface which can be used to interact |
| 159 | +with a running virtual machine. |
| 160 | + |
| 161 | +QMP stands for QEMU Monitor Protocol and is a json based interface. |
| 162 | +HMP stands for Human Monitor Protocol and is a set of text commands available |
| 163 | +for users who prefer natural language to json. |
| 164 | + |
| 165 | +MTTCG |
| 166 | +----- |
| 167 | + |
| 168 | +Multiple CPU support was first implemented using a round-robin algorithm |
| 169 | +running on a single thread. Later on, `Multi-threaded TCG <mttcg>` was developed |
| 170 | +to benefit from multiple cores to speed up execution. |
| 171 | + |
| 172 | +Plugins |
| 173 | +------- |
| 174 | + |
| 175 | +`TCG Plugins <TCG Plugins>` is an API used to instrument guest code, in system |
| 176 | +and user mode. The end goal is to have a similar set of functionality compared |
| 177 | +to `DynamoRIO <https://dynamorio.org/>`_ or `valgrind <https://valgrind.org/>`_. |
| 178 | + |
| 179 | +One key advantage of QEMU plugins is that they can be used to perform |
| 180 | +architecture agnostic instrumentation. |
| 181 | + |
| 182 | +Patchew |
| 183 | +------- |
| 184 | + |
| 185 | +`Patchew <https://patchew.org/QEMU/>`_ is a website that tracks patches on the |
| 186 | +Mailing List. |
| 187 | + |
| 188 | +PR |
| 189 | +-- |
| 190 | + |
| 191 | +Once a series is reviewed and accepted by a subsystem maintainer, it will be |
| 192 | +included in a PR (Pull Request) that the project maintainer will merge into QEMU |
| 193 | +main branch, after running tests. |
| 194 | + |
| 195 | +The QEMU project doesn't currently expect most developers to directly submit |
| 196 | +pull requests. |
| 197 | + |
| 198 | +QCOW2 |
| 199 | +----- |
| 200 | + |
| 201 | +QEMU Copy On Write is a disk format developed by QEMU. It provides transparent |
| 202 | +compression, automatic extension, and many other advantages over a raw image. |
| 203 | + |
| 204 | +qcow2 is the recommended format to use. |
| 205 | + |
| 206 | +QEMU |
| 207 | +---- |
| 208 | + |
| 209 | +`QEMU (Quick Emulator) <https://www.qemu.org/>`_ is a generic and open source |
| 210 | +machine emulator and virtualizer. |
| 211 | + |
| 212 | +QOM |
| 213 | +--- |
| 214 | + |
| 215 | +`QEMU Object Model <qom>` is an object oriented API used to define various |
| 216 | +devices and hardware in the QEMU codebase. |
| 217 | + |
| 218 | +Record/replay |
| 219 | +------------- |
| 220 | + |
| 221 | +`Record/replay <replay>` is a feature of QEMU allowing to have a deterministic |
| 222 | +and reproducible execution of a virtual machine. |
| 223 | + |
| 224 | +Rust |
| 225 | +---- |
| 226 | + |
| 227 | +`A new programming language <https://www.rust-lang.org/>`_, memory safe by |
| 228 | +default. There is a work in progress to integrate it in QEMU codebase for |
| 229 | +various subsystems. |
| 230 | + |
| 231 | +System mode |
| 232 | +----------- |
| 233 | + |
| 234 | +QEMU System mode provides a virtual model of an entire machine (CPU, memory and |
| 235 | +emulated devices) to run a guest OS. In this mode the CPU may be fully emulated, |
| 236 | +or it may work with a hypervisor such as KVM, Xen or Hypervisor.Framework to |
| 237 | +allow the guest to run directly on the host CPU. |
| 238 | + |
| 239 | +QEMU System mode is called :ref:`softmmu <softmmu>` as well. |
| 240 | + |
| 241 | +.. _target: |
| 242 | + |
| 243 | +Target |
| 244 | +------ |
| 245 | + |
| 246 | +The term "target" can be ambiguous. In most places in QEMU it is used as a |
| 247 | +synonym 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 |
| 249 | +architecture which QEMU is running on, i.e. the :ref:`host`. |
| 250 | + |
| 251 | +TCG |
| 252 | +--- |
| 253 | + |
| 254 | +TCG is the QEMU `Tiny Code Generator <tcg>`. It is the JIT (just-in-time) |
| 255 | +compiler we use to emulate a guest CPU in software. |
| 256 | + |
| 257 | +It is one of the accelerators supported by QEMU, and supports a lot of |
| 258 | +guest/host architectures. |
| 259 | + |
| 260 | +User mode |
| 261 | +--------- |
| 262 | + |
| 263 | +QEMU User mode can launch processes compiled for one CPU on another CPU. In this |
| 264 | +mode the CPU is always emulated. In this mode, QEMU translate system calls from |
| 265 | +guest to host kernel. It is available for Linux and BSD. |
| 266 | + |
| 267 | +VirtIO |
| 268 | +------ |
| 269 | + |
| 270 | +VirtIO is an open standard used to define and implement virtual devices with a |
| 271 | +minimal overhead, defining a set of data structures and hypercalls (similar to |
| 272 | +system calls, but targeting an hypervisor, which happens to be QEMU in our |
| 273 | +case). It's designed to be more efficient than emulating a real device, by |
| 274 | +minimizing the amount of interactions between a guest VM and its hypervisor. |
| 275 | + |
| 276 | +vhost-user |
| 277 | +---------- |
| 278 | + |
| 279 | +`Vhost-user <vhost_user>` is an interface used to implement VirtIO devices |
| 280 | +outside of QEMU itself. |
0 commit comments