📄 qemu-tech.html
字号:
<HTML><HEAD><!-- Created by texi2html 1.56k from qemu-tech.texi on 3 May 2006 --><TITLE>QEMU Internals</TITLE></HEAD><BODY><H1>QEMU Internals</H1><P><P><HR><P><H1>Table of Contents</H1><UL><LI><A NAME="TOC1" HREF="qemu-tech.html#SEC1">1. Introduction</A><UL><LI><A NAME="TOC2" HREF="qemu-tech.html#SEC2">1.1 Features</A><LI><A NAME="TOC3" HREF="qemu-tech.html#SEC3">1.2 x86 emulation</A><LI><A NAME="TOC4" HREF="qemu-tech.html#SEC4">1.3 ARM emulation</A><LI><A NAME="TOC5" HREF="qemu-tech.html#SEC5">1.4 PowerPC emulation</A><LI><A NAME="TOC6" HREF="qemu-tech.html#SEC6">1.5 SPARC emulation</A></UL><LI><A NAME="TOC7" HREF="qemu-tech.html#SEC7">2. QEMU Internals</A><UL><LI><A NAME="TOC8" HREF="qemu-tech.html#SEC8">2.1 QEMU compared to other emulators</A><LI><A NAME="TOC9" HREF="qemu-tech.html#SEC9">2.2 Portable dynamic translation</A><LI><A NAME="TOC10" HREF="qemu-tech.html#SEC10">2.3 Register allocation</A><LI><A NAME="TOC11" HREF="qemu-tech.html#SEC11">2.4 Condition code optimisations</A><LI><A NAME="TOC12" HREF="qemu-tech.html#SEC12">2.5 CPU state optimisations</A><LI><A NAME="TOC13" HREF="qemu-tech.html#SEC13">2.6 Translation cache</A><LI><A NAME="TOC14" HREF="qemu-tech.html#SEC14">2.7 Direct block chaining</A><LI><A NAME="TOC15" HREF="qemu-tech.html#SEC15">2.8 Self-modifying code and translated code invalidation</A><LI><A NAME="TOC16" HREF="qemu-tech.html#SEC16">2.9 Exception support</A><LI><A NAME="TOC17" HREF="qemu-tech.html#SEC17">2.10 MMU emulation</A><LI><A NAME="TOC18" HREF="qemu-tech.html#SEC18">2.11 Hardware interrupts</A><LI><A NAME="TOC19" HREF="qemu-tech.html#SEC19">2.12 User emulation specific details</A><UL><LI><A NAME="TOC20" HREF="qemu-tech.html#SEC20">2.12.1 Linux system call translation</A><LI><A NAME="TOC21" HREF="qemu-tech.html#SEC21">2.12.2 Linux signals</A><LI><A NAME="TOC22" HREF="qemu-tech.html#SEC22">2.12.3 clone() system call and threads</A><LI><A NAME="TOC23" HREF="qemu-tech.html#SEC23">2.12.4 Self-virtualization</A></UL><LI><A NAME="TOC24" HREF="qemu-tech.html#SEC24">2.13 Bibliography</A></UL><LI><A NAME="TOC25" HREF="qemu-tech.html#SEC25">3. Regression Tests</A><UL><LI><A NAME="TOC26" HREF="qemu-tech.html#SEC26">3.1 <TT>`test-i386'</TT></A><LI><A NAME="TOC27" HREF="qemu-tech.html#SEC27">3.2 <TT>`linux-test'</TT></A><LI><A NAME="TOC28" HREF="qemu-tech.html#SEC28">3.3 <TT>`qruncom.c'</TT></A></UL><LI><A NAME="TOC29" HREF="qemu-tech.html#SEC29">4. Index</A></UL><P><HR><P><H1><A NAME="SEC1" HREF="qemu-tech.html#TOC1">1. Introduction</A></H1><H2><A NAME="SEC2" HREF="qemu-tech.html#TOC2">1.1 Features</A></H2><P>QEMU is a FAST! processor emulator using a portable dynamictranslator.<P>QEMU has two operating modes:<UL><LI>Full system emulation. In this mode, QEMU emulates a full system(usually a PC), including a processor and various peripherals. It canbe used to launch an different Operating System without rebooting thePC or to debug system code.<LI>User mode emulation (Linux host only). In this mode, QEMU can launchLinux processes compiled for one CPU on another CPU. It can be used tolaunch the Wine Windows API emulator (<A HREF="http://www.winehq.org">http://www.winehq.org</A>) orto ease cross-compilation and cross-debugging.</UL><P>As QEMU requires no host kernel driver to run, it is very safe andeasy to use.<P>QEMU generic features:<UL><LI>User space only or full system emulation.<LI>Using dynamic translation to native code for reasonable speed.<LI>Working on x86 and PowerPC hosts. Being tested on ARM, Sparc32, Alpha and S390.<LI>Self-modifying code support.<LI>Precise exceptions support.<LI>The virtual CPU is a library (<CODE>libqemu</CODE>) which can be usedin other projects (look at <TT>`qemu/tests/qruncom.c'</TT> to have anexample of user mode <CODE>libqemu</CODE> usage).</UL><P>QEMU user mode emulation features:<UL><LI>Generic Linux system call converter, including most ioctls.<LI>clone() emulation using native CPU clone() to use Linux scheduler for threads.<LI>Accurate signal handling by remapping host signals to target signals.</UL><P>QEMU full system emulation features:<UL><LI>QEMU can either use a full software MMU for maximum portability or use the host system call mmap() to simulate the target MMU.</UL><H2><A NAME="SEC3" HREF="qemu-tech.html#TOC3">1.2 x86 emulation</A></H2><P>QEMU x86 target features:<UL><LI>The virtual x86 CPU supports 16 bit and 32 bit addressing with segmentation.LDT/GDT and IDT are emulated. VM86 mode is also supported to run DOSEMU.<LI>Support of host page sizes bigger than 4KB in user mode emulation.<LI>QEMU can emulate itself on x86.<LI>An extensive Linux x86 CPU test program is included <TT>`tests/test-i386'</TT>.It can be used to test other x86 virtual CPUs.</UL><P>Current QEMU limitations:<UL><LI>No SSE/MMX support (yet).<LI>No x86-64 support.<LI>IPC syscalls are missing.<LI>The x86 segment limits and access rights are not tested at everymemory access (yet). Hopefully, very few OSes seem to rely on that fornormal use.<LI>On non x86 host CPUs, <CODE>double</CODE>s are used instead of the non standard10 byte <CODE>long double</CODE>s of x86 for floating point emulation to getmaximum performances.</UL><H2><A NAME="SEC4" HREF="qemu-tech.html#TOC4">1.3 ARM emulation</A></H2><UL><LI>Full ARM 7 user emulation.<LI>NWFPE FPU support included in user Linux emulation.<LI>Can run most ARM Linux binaries.</UL><H2><A NAME="SEC5" HREF="qemu-tech.html#TOC5">1.4 PowerPC emulation</A></H2><UL><LI>Full PowerPC 32 bit emulation, including privileged instructions,FPU and MMU.<LI>Can run most PowerPC Linux binaries.</UL><H2><A NAME="SEC6" HREF="qemu-tech.html#TOC6">1.5 SPARC emulation</A></H2><UL><LI>Somewhat complete SPARC V8 emulation, including privilegedinstructions, FPU and MMU. SPARC V9 emulation includes most privilegedinstructions, FPU and I/D MMU, but misses VIS instructions.<LI>Can run some 32-bit SPARC Linux binaries.</UL><P>Current QEMU limitations:<UL><LI>Tagged add/subtract instructions are not supported, but they areprobably not used.<LI>IPC syscalls are missing.<LI>128-bit floating point operations are not supported, though none of thereal CPUs implement them either. FCMPE[SD] are not correctlyimplemented. Floating point exception support is untested.<LI>Alignment is not enforced at all.<LI>Atomic instructions are not correctly implemented.<LI>Sparc64 emulators are not usable for anything yet.</UL><H1><A NAME="SEC7" HREF="qemu-tech.html#TOC7">2. QEMU Internals</A></H1><H2><A NAME="SEC8" HREF="qemu-tech.html#TOC8">2.1 QEMU compared to other emulators</A></H2><P>Like bochs <A HREF="qemu-tech.html#BIB3">[3]</A>, QEMU emulates an x86 CPU. But QEMU is much faster thanbochs as it uses dynamic compilation. Bochs is closely tied to x86 PCemulation while QEMU can emulate several processors.<P>Like Valgrind <A HREF="qemu-tech.html#BIB2">[2]</A>, QEMU does user space emulation and dynamictranslation. Valgrind is mainly a memory debugger while QEMU has nosupport for it (QEMU could be used to detect out of bound memoryaccesses as Valgrind, but it has no support to track uninitialised dataas Valgrind does). The Valgrind dynamic translator generates better codethan QEMU (in particular it does register allocation) but it is closelytied to an x86 host and target and has no support for precise exceptionsand system emulation.<P>EM86 <A HREF="qemu-tech.html#BIB4">[4]</A> is the closest project to user space QEMU (and QEMU still usessome of its code, in particular the ELF file loader). EM86 was limitedto an alpha host and used a proprietary and slow interpreter (theinterpreter part of the FX!32 Digital Win32 code translator <A HREF="qemu-tech.html#BIB5">[5]</A>).<P>TWIN <A HREF="qemu-tech.html#BIB6">[6]</A> is a Windows API emulator like Wine. It is less accurate thanWine but includes a protected mode x86 interpreter to launch x86 Windowsexecutables. Such an approach has greater potential because most of theWindows API is executed natively but it is far more difficult to developbecause all the data structures and function parameters exchangedbetween the API and the x86 code must be converted.<P>User mode Linux <A HREF="qemu-tech.html#BIB7">[7]</A> was the only solution before QEMU to launch aLinux kernel as a process while not needing any host kernelpatches. However, user mode Linux requires heavy kernel patches whileQEMU accepts unpatched Linux kernels. The price to pay is that QEMU isslower.<P>The new Plex86 <A HREF="qemu-tech.html#BIB8">[8]</A> PC virtualizer is done in the same spirit as theqemu-fast system emulator. It requires a patched Linux kernel to work(you cannot launch the same kernel on your PC), but the patches arereally small. As it is a PC virtualizer (no emulation is done exceptfor some priveledged instructions), it has the potential of beingfaster than QEMU. The downside is that a complicated (and potentiallyunsafe) host kernel patch is needed.<P>The commercial PC Virtualizers (VMWare <A HREF="qemu-tech.html#BIB9">[9]</A>, VirtualPC <A HREF="qemu-tech.html#BIB10">[10]</A>, TwoOStwo<A HREF="qemu-tech.html#BIB11">[11]</A>) are faster than QEMU, but they all need specific, proprietaryand potentially unsafe host drivers. Moreover, they are unable toprovide cycle exact simulation as an emulator can.<H2><A NAME="SEC9" HREF="qemu-tech.html#TOC9">2.2 Portable dynamic translation</A></H2><P>QEMU is a dynamic translator. When it first encounters a piece of code,it converts it to the host instruction set. Usually dynamic translatorsare very complicated and highly CPU dependent. QEMU uses some trickswhich make it relatively easily portable and simple while achieving goodperformances.<P>The basic idea is to split every x86 instruction into fewer simplerinstructions. Each simple instruction is implemented by a piece of Ccode (see <TT>`target-i386/op.c'</TT>). Then a compile time tool(<TT>`dyngen'</TT>) takes the corresponding object file (<TT>`op.o'</TT>)to generate a dynamic code generator which concatenates the simpleinstructions to build a function (see <TT>`op.h:dyngen_code()'</TT>).<P>In essence, the process is similar to <A HREF="qemu-tech.html#BIB1">[1]</A>, but more work is done atcompile time. <P>A key idea to get optimal performances is that constant parameters canbe passed to the simple operations. For that purpose, dummy ELFrelocations are generated with gcc for each constant parameter. Then,the tool (<TT>`dyngen'</TT>) can locate the relocations and generate theappriopriate C code to resolve them when building the dynamic code.<P>That way, QEMU is no more difficult to port than a dynamic linker.<P>To go even faster, GCC static register variables are used to keep thestate of the virtual CPU.<H2><A NAME="SEC10" HREF="qemu-tech.html#TOC10">2.3 Register allocation</A></H2><P>Since QEMU uses fixed simple instructions, no efficient registerallocation can be done. However, because RISC CPUs have a lot ofregister, most of the virtual CPU state can be put in registers withoutdoing complicated register allocation.<H2><A NAME="SEC11" HREF="qemu-tech.html#TOC11">2.4 Condition code optimisations</A></H2><P>Good CPU condition codes emulation (<CODE>EFLAGS</CODE> register on x86) is acritical point to get good performances. QEMU uses lazy condition codeevaluation: instead of computing the condition codes after each x86instruction, it just stores one operand (called <CODE>CC_SRC</CODE>), theresult (called <CODE>CC_DST</CODE>) and the type of operation (called<CODE>CC_OP</CODE>).<P><CODE>CC_OP</CODE> is almost never explicitely set in the generated code⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -