docs/devel/tcg.rst

8 it converts it to the host instruction set. Usually dynamic translators
16 The following sections outline some notable features and implementation
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.
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.
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.
47 Exiting from the TB this way will cause the ``cpu_exec_interrupt()``
52 In order to accelerate the cases where the TB for the new
54 multiple TBs to be chained directly, without having to go back to the
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.
71 The translation code usually implements branching by performing the
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
84 3. Call ``tcg_gen_exit_tb()`` passing the address of the current TB and
85    the jump slot index again.
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
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
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.
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.
112 For the ``goto_tb + exit_tb`` mechanism to be used, the following
115 * The change in CPU state must be constant, e.g., a direct branch and
118 * The direct branch cannot cross a page boundary. Memory mappings
119   may change, causing the code at the destination address to change.
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.
131 instruction cache invalidation is signaled by the application when code
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.
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
157 The host SIGSEGV and SIGBUS signal handlers are used to get invalid
159 target program counter, and looks up where the exception happened
160 based on the host program counter at the exception point.
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
173 For system emulation QEMU uses a software MMU. In that mode, the MMU
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
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.
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
190 Finally, the MMU helps tracking dirty pages and pages pointed to by
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
199 limitation you can use the ``-perfmap`` or the ``-jitdump`` option to generate
202 available); its output needs to be integrated with the ``perf.data`` file
203 before the final report can be viewed.