| 1 | .. _tcg_internals: |
| 2 | |
| 3 | ==================== |
| 4 | Translator Internals |
| 5 | ==================== |
| 6 | |
| 7 | QEMU is a dynamic translator. When it first encounters a piece of code, |
| 8 | it converts it to the host instruction set. Usually dynamic translators |
| 9 | are very complicated and highly CPU dependent. QEMU uses some tricks |
| 10 | which make it relatively easily portable and simple while achieving good |
| 11 | performances. |
| 12 | |
| 13 | QEMU's dynamic translation backend is called TCG, for "Tiny Code |
| 14 | Generator". For more information, please take a look at :ref:`tcg-ops-ref`. |
| 15 | |
| 16 | The following sections outline some notable features and implementation |
| 17 | details of QEMU's dynamic translator. |
| 18 | |
| 19 | CPU state optimisations |
| 20 | ----------------------- |
| 21 | |
| 22 | The target CPUs have many internal states which change the way they |
| 23 | evaluate instructions. In order to achieve a good speed, the |
| 24 | translation phase considers that some state information of the virtual |
| 25 | CPU cannot change in it. The state is recorded in the Translation |
| 26 | Block (TB). If the state changes (e.g. privilege level), a new TB will |
| 27 | be generated and the previous TB won't be used anymore until the state |
| 28 | matches the state recorded in the previous TB. The same idea can be applied |
| 29 | to other aspects of the CPU state. For example, on x86, if the SS, |
| 30 | DS and ES segments have a zero base, then the translator does not even |
| 31 | generate an addition for the segment base. |
| 32 | |
| 33 | Direct block chaining |
| 34 | --------------------- |
| 35 | |
| 36 | After each translated basic block is executed, QEMU uses the simulated |
| 37 | Program Counter (PC) and other CPU state information (such as the CS |
| 38 | segment base value) to find the next basic block. |
| 39 | |
| 40 | In its simplest, less optimized form, this is done by exiting from the |
| 41 | current TB, going through the TB epilogue, and then back to the |
| 42 | main loop. That’s where QEMU looks for the next TB to execute, |
| 43 | translating it from the guest architecture if it isn’t already available |
| 44 | in memory. Then QEMU proceeds to execute this next TB, starting at the |
| 45 | prologue and then moving on to the translated instructions. |
| 46 | |
| 47 | Exiting from the TB this way will cause the ``cpu_exec_interrupt()`` |
| 48 | callback to be re-evaluated before executing additional instructions. |
| 49 | It is mandatory to exit this way after any CPU state changes that may |
| 50 | unmask interrupts. |
| 51 | |
| 52 | In order to accelerate the cases where the TB for the new |
| 53 | simulated PC is already available, QEMU has mechanisms that allow |
| 54 | multiple TBs to be chained directly, without having to go back to the |
| 55 | main loop as described above. These mechanisms are: |
| 56 | |
| 57 | ``lookup_and_goto_ptr`` |
| 58 | ^^^^^^^^^^^^^^^^^^^^^^^ |
| 59 | |
| 60 | Calling ``tcg_gen_lookup_and_goto_ptr()`` will emit a call to |
| 61 | ``helper_lookup_tb_ptr``. This helper will look for an existing TB that |
| 62 | matches the current CPU state. If the destination TB is available its |
| 63 | code address is returned, otherwise the address of the JIT epilogue is |
| 64 | returned. The call to the helper is always followed by the tcg ``goto_ptr`` |
| 65 | opcode, which branches to the returned address. In this way, we either |
| 66 | branch to the next TB or return to the main loop. |
| 67 | |
| 68 | ``goto_tb + exit_tb`` |
| 69 | ^^^^^^^^^^^^^^^^^^^^^ |
| 70 | |
| 71 | The translation code usually implements branching by performing the |
| 72 | following steps: |
| 73 | |
| 74 | 1. Call ``tcg_gen_goto_tb()`` passing a jump slot index (either 0 or 1) |
| 75 | as a parameter. |
| 76 | |
| 77 | 2. Emit TCG instructions to update the CPU state with any information |
| 78 | that has been assumed constant and is required by the main loop to |
| 79 | correctly locate and execute the next TB. For most guests, this is |
| 80 | just the PC of the branch destination, but others may store additional |
| 81 | data. The information updated in this step must be inferable from both |
| 82 | ``cpu_get_tb_cpu_state()`` and ``cpu_restore_state()``. |
| 83 | |
| 84 | 3. Call ``tcg_gen_exit_tb()`` passing the address of the current TB and |
| 85 | the jump slot index again. |
| 86 | |
| 87 | Step 1, ``tcg_gen_goto_tb()``, will emit a ``goto_tb`` TCG |
| 88 | instruction that later on gets translated to a jump to an address |
| 89 | associated with the specified jump slot. Initially, this is the address |
| 90 | of step 2's instructions, which update the CPU state information. Step 3, |
| 91 | ``tcg_gen_exit_tb()``, exits from the current TB returning a tagged |
| 92 | pointer composed of the last executed TB’s address and the jump slot |
| 93 | index. |
| 94 | |
| 95 | The first time this whole sequence is executed, step 1 simply jumps |
| 96 | to step 2. Then the CPU state information gets updated and we exit from |
| 97 | the current TB. As a result, the behavior is very similar to the less |
| 98 | optimized form described earlier in this section. |
| 99 | |
| 100 | Next, the main loop looks for the next TB to execute using the |
| 101 | current CPU state information (creating the TB if it wasn’t already |
| 102 | available) and, before starting to execute the new TB’s instructions, |
| 103 | patches the previously executed TB by associating one of its jump |
| 104 | slots (the one specified in the call to ``tcg_gen_exit_tb()``) with the |
| 105 | address of the new TB. |
| 106 | |
| 107 | The next time this previous TB is executed and we get to that same |
| 108 | ``goto_tb`` step, it will already be patched (assuming the destination TB |
| 109 | is still in memory) and will jump directly to the first instruction of |
| 110 | the destination TB, without going back to the main loop. |
| 111 | |
| 112 | For the ``goto_tb + exit_tb`` mechanism to be used, the following |
| 113 | conditions need to be satisfied: |
| 114 | |
| 115 | * The change in CPU state must be constant, e.g., a direct branch and |
| 116 | not an indirect branch. |
| 117 | |
| 118 | * The direct branch cannot cross a page boundary. Memory mappings |
| 119 | may change, causing the code at the destination address to change. |
| 120 | |
| 121 | Note that, on step 3 (``tcg_gen_exit_tb()``), in addition to the |
| 122 | jump slot index, the address of the TB just executed is also returned. |
| 123 | This address corresponds to the TB that will be patched; it may be |
| 124 | different than the one that was directly executed from the main loop |
| 125 | if the latter had already been chained to other TBs. |
| 126 | |
| 127 | Self-modifying code and translated code invalidation |
| 128 | ---------------------------------------------------- |
| 129 | |
| 130 | Self-modifying code is a special challenge in x86 emulation because no |
| 131 | instruction cache invalidation is signaled by the application when code |
| 132 | is modified. |
| 133 | |
| 134 | User-mode emulation marks a host page as write-protected (if it is |
| 135 | not already read-only) every time translated code is generated for a |
| 136 | basic block. Then, if a write access is done to the page, Linux raises |
| 137 | a SEGV signal. QEMU then invalidates all the translated code in the page |
| 138 | and enables write accesses to the page. For system emulation, write |
| 139 | protection is achieved through the software MMU. |
| 140 | |
| 141 | Correct translated code invalidation is done efficiently by maintaining |
| 142 | a linked list of every translated block contained in a given page. Other |
| 143 | linked lists are also maintained to undo direct block chaining. |
| 144 | |
| 145 | On RISC targets, correctly written software uses memory barriers and |
| 146 | cache flushes, so some of the protection above would not be |
| 147 | necessary. However, QEMU still requires that the generated code always |
| 148 | matches the target instructions in memory in order to handle |
| 149 | exceptions correctly. |
| 150 | |
| 151 | Exception support |
| 152 | ----------------- |
| 153 | |
| 154 | longjmp() is used when an exception such as division by zero is |
| 155 | encountered. |
| 156 | |
| 157 | The host SIGSEGV and SIGBUS signal handlers are used to get invalid |
| 158 | memory accesses. QEMU keeps a map from host program counter to |
| 159 | target program counter, and looks up where the exception happened |
| 160 | based on the host program counter at the exception point. |
| 161 | |
| 162 | On some targets, some bits of the virtual CPU's state are not flushed to the |
| 163 | memory until the end of the translation block. This is done for internal |
| 164 | emulation state that is rarely accessed directly by the program and/or changes |
| 165 | very often throughout the execution of a translation block---this includes |
| 166 | condition codes on x86, delay slots on SPARC, conditional execution on |
| 167 | Arm, and so on. This state is stored for each target instruction, and |
| 168 | looked up on exceptions. |
| 169 | |
| 170 | MMU emulation |
| 171 | ------------- |
| 172 | |
| 173 | For system emulation QEMU uses a software MMU. In that mode, the MMU |
| 174 | virtual to physical address translation is done at every memory |
| 175 | access. |
| 176 | |
| 177 | QEMU uses an address translation cache (TLB) to speed up the translation. |
| 178 | In order to avoid flushing the translated code each time the MMU |
| 179 | mappings change, all caches in QEMU are physically indexed. This |
| 180 | means that each basic block is indexed with its physical address. |
| 181 | |
| 182 | In order to avoid invalidating the basic block chain when MMU mappings |
| 183 | change, chaining is only performed when the destination of the jump |
| 184 | shares a page with the basic block that is performing the jump. |
| 185 | |
| 186 | The MMU can also distinguish RAM and ROM memory areas from MMIO memory |
| 187 | areas. Access is faster for RAM and ROM because the translation cache also |
| 188 | hosts the offset between guest address and host memory. Accessing MMIO |
| 189 | memory areas instead calls out to C code for device emulation. |
| 190 | Finally, the MMU helps tracking dirty pages and pages pointed to by |
| 191 | translation blocks. |
| 192 | |
| 193 | Profiling JITted code |
| 194 | --------------------- |
| 195 | |
| 196 | The Linux ``perf`` tool will treat all JITted code as a single block as |
| 197 | unlike the main code it can't use debug information to link individual |
| 198 | program counter samples with larger functions. To overcome this |
| 199 | limitation you can use the ``-perfmap`` or the ``-jitdump`` option to generate |
| 200 | map files. ``-perfmap`` is lightweight and produces only guest-host mappings. |
| 201 | ``-jitdump`` additionally saves JITed code and guest debug information (if |
| 202 | available); its output needs to be integrated with the ``perf.data`` file |
| 203 | before the final report can be viewed. |
| 204 | |
| 205 | .. code:: |
| 206 | |
| 207 | perf record $QEMU -perfmap $REMAINING_ARGS |
| 208 | perf report |
| 209 | |
| 210 | perf record -k 1 $QEMU -jitdump $REMAINING_ARGS |
| 211 | DEBUGINFOD_URLS= perf inject -j -i perf.data -o perf.data.jitted |
| 212 | perf report -i perf.data.jitted |
| 213 | |
| 214 | Note that qemu-system generates mappings only for ``-kernel`` files in ELF |
| 215 | format. |