1==================== 2Translator Internals 3==================== 4 5QEMU is a dynamic translator. When it first encounters a piece of code, 6it converts it to the host instruction set. Usually dynamic translators 7are very complicated and highly CPU dependent. QEMU uses some tricks 8which make it relatively easily portable and simple while achieving good 9performances. 10 11QEMU's dynamic translation backend is called TCG, for "Tiny Code 12Generator". For more information, please take a look at ``tcg/README``. 13 14Some notable features of QEMU's dynamic translator are: 15 16CPU state optimisations 17----------------------- 18 19The target CPUs have many internal states which change the way it 20evaluates instructions. In order to achieve a good speed, the 21translation phase considers that some state information of the virtual 22CPU cannot change in it. The state is recorded in the Translation 23Block (TB). If the state changes (e.g. privilege level), a new TB will 24be generated and the previous TB won't be used anymore until the state 25matches the state recorded in the previous TB. The same idea can be applied 26to other aspects of the CPU state. For example, on x86, if the SS, 27DS and ES segments have a zero base, then the translator does not even 28generate an addition for the segment base. 29 30Direct block chaining 31--------------------- 32 33After each translated basic block is executed, QEMU uses the simulated 34Program Counter (PC) and other cpu state information (such as the CS 35segment base value) to find the next basic block. 36 37In order to accelerate the most common cases where the new simulated PC 38is known, QEMU can patch a basic block so that it jumps directly to the 39next one. 40 41The most portable code uses an indirect jump. An indirect jump makes 42it easier to make the jump target modification atomic. On some host 43architectures (such as x86 or PowerPC), the ``JUMP`` opcode is 44directly patched so that the block chaining has no overhead. 45 46Self-modifying code and translated code invalidation 47---------------------------------------------------- 48 49Self-modifying code is a special challenge in x86 emulation because no 50instruction cache invalidation is signaled by the application when code 51is modified. 52 53User-mode emulation marks a host page as write-protected (if it is 54not already read-only) every time translated code is generated for a 55basic block. Then, if a write access is done to the page, Linux raises 56a SEGV signal. QEMU then invalidates all the translated code in the page 57and enables write accesses to the page. For system emulation, write 58protection is achieved through the software MMU. 59 60Correct translated code invalidation is done efficiently by maintaining 61a linked list of every translated block contained in a given page. Other 62linked lists are also maintained to undo direct block chaining. 63 64On RISC targets, correctly written software uses memory barriers and 65cache flushes, so some of the protection above would not be 66necessary. However, QEMU still requires that the generated code always 67matches the target instructions in memory in order to handle 68exceptions correctly. 69 70Exception support 71----------------- 72 73longjmp() is used when an exception such as division by zero is 74encountered. 75 76The host SIGSEGV and SIGBUS signal handlers are used to get invalid 77memory accesses. QEMU keeps a map from host program counter to 78target program counter, and looks up where the exception happened 79based on the host program counter at the exception point. 80 81On some targets, some bits of the virtual CPU's state are not flushed to the 82memory until the end of the translation block. This is done for internal 83emulation state that is rarely accessed directly by the program and/or changes 84very often throughout the execution of a translation block---this includes 85condition codes on x86, delay slots on SPARC, conditional execution on 86Arm, and so on. This state is stored for each target instruction, and 87looked up on exceptions. 88 89MMU emulation 90------------- 91 92For system emulation QEMU uses a software MMU. In that mode, the MMU 93virtual to physical address translation is done at every memory 94access. 95 96QEMU uses an address translation cache (TLB) to speed up the translation. 97In order to avoid flushing the translated code each time the MMU 98mappings change, all caches in QEMU are physically indexed. This 99means that each basic block is indexed with its physical address. 100 101In order to avoid invalidating the basic block chain when MMU mappings 102change, chaining is only performed when the destination of the jump 103shares a page with the basic block that is performing the jump. 104 105The MMU can also distinguish RAM and ROM memory areas from MMIO memory 106areas. Access is faster for RAM and ROM because the translation cache also 107hosts the offset between guest address and host memory. Accessing MMIO 108memory areas instead calls out to C code for device emulation. 109Finally, the MMU helps tracking dirty pages and pages pointed to by 110translation blocks. 111 112