qemu-tech.texi

qemu虚拟机代码

\input texinfo @c -*- texinfo -*-
@c %**start of header
@setfilename qemu-tech.info
@settitle QEMU Internals
@exampleindent 0
@paragraphindent 0
@c %**end of header

@iftex
@titlepage
@sp 7
@center @titlefont{QEMU Internals}
@sp 3
@end titlepage
@end iftex

@ifnottex
@node Top
@top

@menu
* Introduction::
* QEMU Internals::
* Regression Tests::
* Index::
@end menu
@end ifnottex

@contents

@node Introduction
@chapter Introduction

@menu
* intro_features::        Features
* intro_x86_emulation::   x86 emulation
* intro_arm_emulation::   ARM emulation
* intro_ppc_emulation::   PowerPC emulation
* intro_sparc_emulation:: SPARC emulation
@end menu

@node intro_features
@section Features

QEMU is a FAST! processor emulator using a portable dynamic
translator.

QEMU has two operating modes:

@itemize @minus

@item 
Full system emulation. In this mode, QEMU emulates a full system
(usually a PC), including a processor and various peripherals. It can
be used to launch an different Operating System without rebooting the
PC or to debug system code.

@item 
User mode emulation (Linux host only). In this mode, QEMU can launch
Linux processes compiled for one CPU on another CPU. It can be used to
launch the Wine Windows API emulator (@url{http://www.winehq.org}) or
to ease cross-compilation and cross-debugging.

@end itemize

As QEMU requires no host kernel driver to run, it is very safe and
easy to use.

QEMU generic features:

@itemize 

@item User space only or full system emulation.

@item Using dynamic translation to native code for reasonable speed.

@item Working on x86 and PowerPC hosts. Being tested on ARM, Sparc32, Alpha and S390.

@item Self-modifying code support.

@item Precise exceptions support.

@item The virtual CPU is a library (@code{libqemu}) which can be used 
in other projects (look at @file{qemu/tests/qruncom.c} to have an
example of user mode @code{libqemu} usage).

@end itemize

QEMU user mode emulation features:
@itemize 
@item Generic Linux system call converter, including most ioctls.

@item clone() emulation using native CPU clone() to use Linux scheduler for threads.

@item Accurate signal handling by remapping host signals to target signals. 
@end itemize

QEMU full system emulation features:
@itemize 
@item QEMU can either use a full software MMU for maximum portability or use the host system call mmap() to simulate the target MMU.
@end itemize

@node intro_x86_emulation
@section x86 emulation

QEMU x86 target features:

@itemize 

@item 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.

@item Support of host page sizes bigger than 4KB in user mode emulation.

@item QEMU can emulate itself on x86.

@item An extensive Linux x86 CPU test program is included @file{tests/test-i386}. 
It can be used to test other x86 virtual CPUs.

@end itemize

Current QEMU limitations:

@itemize 

@item No SSE/MMX support (yet).

@item No x86-64 support.

@item IPC syscalls are missing.

@item The x86 segment limits and access rights are not tested at every 
memory access (yet). Hopefully, very few OSes seem to rely on that for
normal use.

@item On non x86 host CPUs, @code{double}s are used instead of the non standard 
10 byte @code{long double}s of x86 for floating point emulation to get
maximum performances.

@end itemize

@node intro_arm_emulation
@section ARM emulation

@itemize

@item Full ARM 7 user emulation.

@item NWFPE FPU support included in user Linux emulation.

@item Can run most ARM Linux binaries.

@end itemize

@node intro_ppc_emulation
@section PowerPC emulation

@itemize

@item Full PowerPC 32 bit emulation, including privileged instructions, 
FPU and MMU.

@item Can run most PowerPC Linux binaries.

@end itemize

@node intro_sparc_emulation
@section SPARC emulation

@itemize

@item Somewhat complete SPARC V8 emulation, including privileged
instructions, FPU and MMU. SPARC V9 emulation includes most privileged
instructions, FPU and I/D MMU, but misses VIS instructions.

@item Can run some 32-bit SPARC Linux binaries.

@end itemize

Current QEMU limitations:

@itemize 

@item Tagged add/subtract instructions are not supported, but they are
probably not used.

@item IPC syscalls are missing.

@item 128-bit floating point operations are not supported, though none of the
real CPUs implement them either. FCMPE[SD] are not correctly
implemented.  Floating point exception support is untested.

@item Alignment is not enforced at all.

@item Atomic instructions are not correctly implemented.

@item Sparc64 emulators are not usable for anything yet.

@end itemize

@node QEMU Internals
@chapter QEMU Internals

@menu
* QEMU compared to other emulators::
* Portable dynamic translation::
* Register allocation::
* Condition code optimisations::
* CPU state optimisations::
* Translation cache::
* Direct block chaining::
* Self-modifying code and translated code invalidation::
* Exception support::
* MMU emulation::
* Hardware interrupts::
* User emulation specific details::
* Bibliography::
@end menu

@node QEMU compared to other emulators
@section QEMU compared to other emulators

Like bochs [3], QEMU emulates an x86 CPU. But QEMU is much faster than
bochs as it uses dynamic compilation. Bochs is closely tied to x86 PC
emulation while QEMU can emulate several processors.

Like Valgrind [2], QEMU does user space emulation and dynamic
translation. Valgrind is mainly a memory debugger while QEMU has no
support for it (QEMU could be used to detect out of bound memory
accesses as Valgrind, but it has no support to track uninitialised data
as Valgrind does). The Valgrind dynamic translator generates better code
than QEMU (in particular it does register allocation) but it is closely
tied to an x86 host and target and has no support for precise exceptions
and system emulation.

EM86 [4] is the closest project to user space QEMU (and QEMU still uses
some of its code, in particular the ELF file loader). EM86 was limited
to an alpha host and used a proprietary and slow interpreter (the
interpreter part of the FX!32 Digital Win32 code translator [5]).

TWIN [6] is a Windows API emulator like Wine. It is less accurate than
Wine but includes a protected mode x86 interpreter to launch x86 Windows
executables. Such an approach has greater potential because most of the
Windows API is executed natively but it is far more difficult to develop
because all the data structures and function parameters exchanged
between the API and the x86 code must be converted.

User mode Linux [7] was the only solution before QEMU to launch a
Linux kernel as a process while not needing any host kernel
patches. However, user mode Linux requires heavy kernel patches while
QEMU accepts unpatched Linux kernels. The price to pay is that QEMU is
slower.

The new Plex86 [8] PC virtualizer is done in the same spirit as the
qemu-fast system emulator. It requires a patched Linux kernel to work
(you cannot launch the same kernel on your PC), but the patches are
really small. As it is a PC virtualizer (no emulation is done except
for some priveledged instructions), it has the potential of being
faster than QEMU. The downside is that a complicated (and potentially
unsafe) host kernel patch is needed.

The commercial PC Virtualizers (VMWare [9], VirtualPC [10], TwoOStwo
[11]) are faster than QEMU, but they all need specific, proprietary
and potentially unsafe host drivers. Moreover, they are unable to
provide cycle exact simulation as an emulator can.

@node Portable dynamic translation
@section Portable dynamic translation

QEMU is a dynamic translator. When it first encounters a piece of code,
it converts it to the host instruction set. Usually dynamic translators
are very complicated and highly CPU dependent. QEMU uses some tricks
which make it relatively easily portable and simple while achieving good
performances.

The basic idea is to split every x86 instruction into fewer simpler
instructions. Each simple instruction is implemented by a piece of C
code (see @file{target-i386/op.c}). Then a compile time tool
(@file{dyngen}) takes the corresponding object file (@file{op.o})
to generate a dynamic code generator which concatenates the simple
instructions to build a function (see @file{op.h:dyngen_code()}).

In essence, the process is similar to [1], but more work is done at
compile time. 

A key idea to get optimal performances is that constant parameters can
be passed to the simple operations. For that purpose, dummy ELF
relocations are generated with gcc for each constant parameter. Then,
the tool (@file{dyngen}) can locate the relocations and generate the
appriopriate C code to resolve them when building the dynamic code.

That way, QEMU is no more difficult to port than a dynamic linker.

To go even faster, GCC static register variables are used to keep the
state of the virtual CPU.

@node Register allocation
@section Register allocation