Explore how QEMU facilitates emulation for running programs on different machine architectures, its various components, and the implementation of micro-operations to bridge the gap between target and host CPUs efficiently.
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.
E N D
Presentation Transcript
QEMU, a Fast and Portable Dynamic Translator Fabrice Bellard (affiliation?) CMSC 691 talk by Charles Nicholas
Overview QEMU is a system for creating emulators, i.e. programs that allow programs for Target machine A to run on Host machine B For example, to allow a MIPS program (an OS plus apps) to run on an i386 or x64 host By pre-compiling micro operations that make up guest machine instructions, QEMU gains speed over other approaches
Whats the Problem? We want to run a binary for CPU A, but we only have machine B, so we need to emulate A Testing a cross-compiler which has A as a target We need to keep a lower profile than VirtualBox
QEMU Has Many Parts DYNGEN performs runtime conversion of the target CPU instructions into the host instruction set focus of this paper debugger UNIX user mode emulated devices (many more may exist now) and a GUI!
Example: PowerPC to x86 PowerPC instruction addi r1, r1, -16 # r1=r1-16 Generated micro operations mov1_T0_r1 add1_T0_im -16 mov1_r1_T0 These micro ops are implemented in C, as follows... # T0=r1 # T0=T0-16 # r1=T0
Implement Each Micro Op To implement the micro op mov1_T0_r1 A short C function is written void op_mov1_T0_r1(void){ T0 = env->regs[1]; } The various target CPU registers are part of the environment data structure, and T0 is a variable # T0=r1
How Are These Functions Used? The various micro op functions are compiled, and object code stored When a target instruction is first found, the micro op object code sequences are concatenated in memory, and cached System calls such as memcpy are used to handle target machine memory operations Each target machine opcode needs to be handled (one would expect)
How Does DYNGEN Work? The compiled C code (somefile.obj) is parsed, and the location of various micro ops noted. The number of parameters of each micro op is noted, too. GCC flags are used to simplify the parsing, and to assure that the micro op code is position- independent. (Do you know what that means? Am I right on this point?)
Implementation Aspects Target operations are grouped into Translated Blocks, delimited by branching ops Translated Blocks are cached (to avoid translating the same code repeatedly) Target CPU registers (including condition code flags) are just C variables The Translated Blocks may have extra code to branch to each other, if that s what would happen in target code. (Direct Block Chaining)
Other Issues Memory Management Self-modifying code (which malware may use!) Exceptions Interrupts
Evaluation The BYTEmark benchmark for Linux was run on a native host, and then on a QEMU virtual machine. integer code 4x floating point code 10x faster than Bochs by 30x faster than valgrind by 1.2x, even though valgrind is hand coded for x86 to x86 emulation
Conclusions It s possible to make a versatile emulator with decent performance versatile: many (target, host) combinations Lots of options regarding debugging or instrumenting code There seems to be an active QEMU community For more info, see http://wiki.qemu.org
