root / qemu-doc.texi @ 378180d8
History | View | Annotate | Download (13.8 kB)
1 |
\input texinfo @c -*- texinfo -*- |
---|---|
2 |
|
3 |
@settitle QEMU x86 Emulator Reference Documentation |
4 |
@titlepage |
5 |
@sp 7 |
6 |
@center @titlefont{QEMU x86 Emulator Reference Documentation} |
7 |
@sp 3 |
8 |
@end titlepage |
9 |
|
10 |
@chapter Introduction |
11 |
|
12 |
QEMU is an x86 processor emulator. Its purpose is to run x86 Linux |
13 |
processes on non-x86 Linux architectures such as PowerPC or ARM. By |
14 |
using dynamic translation it achieves a reasonnable speed while being |
15 |
easy to port on new host CPUs. Its main goal is to be able to launch the |
16 |
@code{Wine} Windows API emulator (@url{http://www.winehq.org}) on |
17 |
non-x86 CPUs. |
18 |
|
19 |
QEMU features: |
20 |
|
21 |
@itemize |
22 |
|
23 |
@item User space only x86 emulator. |
24 |
|
25 |
@item Currently ported on i386, PowerPC and S390. |
26 |
|
27 |
@item Using dynamic translation to native code for reasonnable speed. |
28 |
|
29 |
@item The virtual x86 CPU supports 16 bit and 32 bit addressing with segmentation. |
30 |
User space LDT and GDT are emulated. VM86 mode is also supported |
31 |
(experimental). |
32 |
|
33 |
@item Generic Linux system call converter, including most ioctls. |
34 |
|
35 |
@item clone() emulation using native CPU clone() to use Linux scheduler for threads. |
36 |
|
37 |
@item Accurate signal handling by remapping host signals to virtual x86 signals. |
38 |
|
39 |
@item QEMU can emulate itself on x86 (experimental). |
40 |
|
41 |
@item The virtual x86 CPU is a library (@code{libqemu}) which can be used |
42 |
in other projects. |
43 |
|
44 |
@item An extensive Linux x86 CPU test program is included @file{tests/test-i386}. |
45 |
It can be used to test other x86 virtual CPUs. |
46 |
|
47 |
@end itemize |
48 |
|
49 |
Current QEMU Limitations: |
50 |
|
51 |
@itemize |
52 |
|
53 |
@item Not all x86 exceptions are precise (yet). [Very few programs need that]. |
54 |
|
55 |
@item No support for self-modifying code (yet). [Very few programs need that, a notable exception is QEMU itself !]. |
56 |
|
57 |
@item No SSE/MMX support (yet). |
58 |
|
59 |
@item No x86-64 support. |
60 |
|
61 |
@item Some Linux syscalls are missing. |
62 |
|
63 |
@item The x86 segment limits and access rights are not tested at every |
64 |
memory access (and will never be to have good performances). |
65 |
|
66 |
@item On non x86 host CPUs, @code{double}s are used instead of the non standard |
67 |
10 byte @code{long double}s of x86 for floating point emulation to get |
68 |
maximum performances. |
69 |
|
70 |
@end itemize |
71 |
|
72 |
@chapter Invocation |
73 |
|
74 |
@section Quick Start |
75 |
|
76 |
In order to launch a Linux process, QEMU needs the process executable |
77 |
itself and all the target (x86) dynamic libraries used by it. |
78 |
|
79 |
@itemize |
80 |
|
81 |
@item On x86, you can just try to launch any process by using the native |
82 |
libraries: |
83 |
|
84 |
@example |
85 |
qemu -L / /bin/ls |
86 |
@end example |
87 |
|
88 |
@code{-L /} tells that the x86 dynamic linker must be searched with a |
89 |
@file{/} prefix. |
90 |
|
91 |
@item Since QEMU is also a linux process, you can launch qemu with qemu: |
92 |
|
93 |
@example |
94 |
qemu -L / qemu -L / /bin/ls |
95 |
@end example |
96 |
|
97 |
@item On non x86 CPUs, you need first to download at least an x86 glibc |
98 |
(@file{qemu-XXX-i386-glibc21.tar.gz} on the QEMU web page). Ensure that |
99 |
@code{LD_LIBRARY_PATH} is not set: |
100 |
|
101 |
@example |
102 |
unset LD_LIBRARY_PATH |
103 |
@end example |
104 |
|
105 |
Then you can launch the precompiled @file{ls} x86 executable: |
106 |
|
107 |
@example |
108 |
qemu /usr/local/qemu-i386/bin/ls-i386 |
109 |
@end example |
110 |
You can look at @file{/usr/local/qemu-i386/bin/qemu-conf.sh} so that |
111 |
QEMU is automatically launched by the Linux kernel when you try to |
112 |
launch x86 executables. It requires the @code{binfmt_misc} module in the |
113 |
Linux kernel. |
114 |
|
115 |
@item The x86 version of QEMU is also included. You can try weird things such as: |
116 |
@example |
117 |
qemu /usr/local/qemu-i386/bin/qemu-i386 /usr/local/qemu-i386/bin/ls-i386 |
118 |
@end example |
119 |
|
120 |
@end itemize |
121 |
|
122 |
@section Wine launch (Currently only tested when emulating x86 on x86) |
123 |
|
124 |
@itemize |
125 |
|
126 |
@item Ensure that you have a working QEMU with the x86 glibc |
127 |
distribution (see previous section). In order to verify it, you must be |
128 |
able to do: |
129 |
|
130 |
@example |
131 |
qemu /usr/local/qemu-i386/bin/ls-i386 |
132 |
@end example |
133 |
|
134 |
@item Download the binary x86 Wine install |
135 |
(@file{qemu-XXX-i386-wine.tar.gz} on the QEMU web page). |
136 |
|
137 |
@item Configure Wine on your account. Look at the provided script |
138 |
@file{/usr/local/qemu-i386/bin/wine-conf.sh}. Your previous |
139 |
@code{$@{HOME@}/.wine} directory is saved to @code{$@{HOME@}/.wine.org}. |
140 |
|
141 |
@item Then you can try the example @file{putty.exe}: |
142 |
|
143 |
@example |
144 |
qemu /usr/local/qemu-i386/wine/bin/wine /usr/local/qemu-i386/wine/c/Program\ Files/putty.exe |
145 |
@end example |
146 |
|
147 |
@end itemize |
148 |
|
149 |
@section Command line options |
150 |
|
151 |
@example |
152 |
usage: qemu [-h] [-d] [-L path] [-s size] program [arguments...] |
153 |
@end example |
154 |
|
155 |
@table @samp |
156 |
@item -h |
157 |
Print the help |
158 |
@item -d |
159 |
Activate log (logfile=/tmp/qemu.log) |
160 |
@item -L path |
161 |
Set the x86 elf interpreter prefix (default=/usr/local/qemu-i386) |
162 |
@item -s size |
163 |
Set the x86 stack size in bytes (default=524288) |
164 |
@end table |
165 |
|
166 |
@chapter QEMU Internals |
167 |
|
168 |
@section QEMU compared to other emulators |
169 |
|
170 |
Unlike bochs [3], QEMU emulates only a user space x86 CPU. It means that |
171 |
you cannot launch an operating system with it. The benefit is that it is |
172 |
simpler and faster due to the fact that some of the low level CPU state |
173 |
can be ignored (in particular, no virtual memory needs to be emulated). |
174 |
|
175 |
Like Valgrind [2], QEMU does user space emulation and dynamic |
176 |
translation. Valgrind is mainly a memory debugger while QEMU has no |
177 |
support for it (QEMU could be used to detect out of bound memory accesses |
178 |
as Valgrind, but it has no support to track uninitialised data as |
179 |
Valgrind does). Valgrind dynamic translator generates better code than |
180 |
QEMU (in particular it does register allocation) but it is closely tied |
181 |
to an x86 host. |
182 |
|
183 |
EM86 [4] is the closest project to QEMU (and QEMU still uses some of its |
184 |
code, in particular the ELF file loader). EM86 was limited to an alpha |
185 |
host and used a proprietary and slow interpreter (the interpreter part |
186 |
of the FX!32 Digital Win32 code translator [5]). |
187 |
|
188 |
TWIN [6] is a Windows API emulator like Wine. It is less accurate than |
189 |
Wine but includes a protected mode x86 interpreter to launch x86 Windows |
190 |
executables. Such an approach as greater potential because most of the |
191 |
Windows API is executed natively but it is far more difficult to develop |
192 |
because all the data structures and function parameters exchanged |
193 |
between the API and the x86 code must be converted. |
194 |
|
195 |
@section Portable dynamic translation |
196 |
|
197 |
QEMU is a dynamic translator. When it first encounters a piece of code, |
198 |
it converts it to the host instruction set. Usually dynamic translators |
199 |
are very complicated and highly CPU dependant. QEMU uses some tricks |
200 |
which make it relatively easily portable and simple while achieving good |
201 |
performances. |
202 |
|
203 |
The basic idea is to split every x86 instruction into fewer simpler |
204 |
instructions. Each simple instruction is implemented by a piece of C |
205 |
code (see @file{op-i386.c}). Then a compile time tool (@file{dyngen}) |
206 |
takes the corresponding object file (@file{op-i386.o}) to generate a |
207 |
dynamic code generator which concatenates the simple instructions to |
208 |
build a function (see @file{op-i386.h:dyngen_code()}). |
209 |
|
210 |
In essence, the process is similar to [1], but more work is done at |
211 |
compile time. |
212 |
|
213 |
A key idea to get optimal performances is that constant parameters can |
214 |
be passed to the simple operations. For that purpose, dummy ELF |
215 |
relocations are generated with gcc for each constant parameter. Then, |
216 |
the tool (@file{dyngen}) can locate the relocations and generate the |
217 |
appriopriate C code to resolve them when building the dynamic code. |
218 |
|
219 |
That way, QEMU is no more difficult to port than a dynamic linker. |
220 |
|
221 |
To go even faster, GCC static register variables are used to keep the |
222 |
state of the virtual CPU. |
223 |
|
224 |
@section Register allocation |
225 |
|
226 |
Since QEMU uses fixed simple instructions, no efficient register |
227 |
allocation can be done. However, because RISC CPUs have a lot of |
228 |
register, most of the virtual CPU state can be put in registers without |
229 |
doing complicated register allocation. |
230 |
|
231 |
@section Condition code optimisations |
232 |
|
233 |
Good CPU condition codes emulation (@code{EFLAGS} register on x86) is a |
234 |
critical point to get good performances. QEMU uses lazy condition code |
235 |
evaluation: instead of computing the condition codes after each x86 |
236 |
instruction, it just stores one operand (called @code{CC_SRC}), the |
237 |
result (called @code{CC_DST}) and the type of operation (called |
238 |
@code{CC_OP}). |
239 |
|
240 |
@code{CC_OP} is almost never explicitely set in the generated code |
241 |
because it is known at translation time. |
242 |
|
243 |
In order to increase performances, a backward pass is performed on the |
244 |
generated simple instructions (see |
245 |
@code{translate-i386.c:optimize_flags()}). When it can be proved that |
246 |
the condition codes are not needed by the next instructions, no |
247 |
condition codes are computed at all. |
248 |
|
249 |
@section CPU state optimisations |
250 |
|
251 |
The x86 CPU has many internal states which change the way it evaluates |
252 |
instructions. In order to achieve a good speed, the translation phase |
253 |
considers that some state information of the virtual x86 CPU cannot |
254 |
change in it. For example, if the SS, DS and ES segments have a zero |
255 |
base, then the translator does not even generate an addition for the |
256 |
segment base. |
257 |
|
258 |
[The FPU stack pointer register is not handled that way yet]. |
259 |
|
260 |
@section Translation cache |
261 |
|
262 |
A 2MByte cache holds the most recently used translations. For |
263 |
simplicity, it is completely flushed when it is full. A translation unit |
264 |
contains just a single basic block (a block of x86 instructions |
265 |
terminated by a jump or by a virtual CPU state change which the |
266 |
translator cannot deduce statically). |
267 |
|
268 |
[Currently, the translated code is not patched if it jumps to another |
269 |
translated code]. |
270 |
|
271 |
@section Exception support |
272 |
|
273 |
longjmp() is used when an exception such as division by zero is |
274 |
encountered. The host SIGSEGV and SIGBUS signal handlers are used to get |
275 |
invalid memory accesses. |
276 |
|
277 |
[Currently, the virtual CPU cannot retrieve the exact CPU state in some |
278 |
exceptions, although it could except for the @code{EFLAGS} register]. |
279 |
|
280 |
@section Linux system call translation |
281 |
|
282 |
QEMU includes a generic system call translator for Linux. It means that |
283 |
the parameters of the system calls can be converted to fix the |
284 |
endianness and 32/64 bit issues. The IOCTLs are converted with a generic |
285 |
type description system (see @file{ioctls.h} and @file{thunk.c}). |
286 |
|
287 |
@section Linux signals |
288 |
|
289 |
Normal and real-time signals are queued along with their information |
290 |
(@code{siginfo_t}) as it is done in the Linux kernel. Then an interrupt |
291 |
request is done to the virtual CPU. When it is interrupted, one queued |
292 |
signal is handled by generating a stack frame in the virtual CPU as the |
293 |
Linux kernel does. The @code{sigreturn()} system call is emulated to return |
294 |
from the virtual signal handler. |
295 |
|
296 |
Some signals (such as SIGALRM) directly come from the host. Other |
297 |
signals are synthetized from the virtual CPU exceptions such as SIGFPE |
298 |
when a division by zero is done (see @code{main.c:cpu_loop()}). |
299 |
|
300 |
The blocked signal mask is still handled by the host Linux kernel so |
301 |
that most signal system calls can be redirected directly to the host |
302 |
Linux kernel. Only the @code{sigaction()} and @code{sigreturn()} system |
303 |
calls need to be fully emulated (see @file{signal.c}). |
304 |
|
305 |
@section clone() system call and threads |
306 |
|
307 |
The Linux clone() system call is usually used to create a thread. QEMU |
308 |
uses the host clone() system call so that real host threads are created |
309 |
for each emulated thread. One virtual CPU instance is created for each |
310 |
thread. |
311 |
|
312 |
The virtual x86 CPU atomic operations are emulated with a global lock so |
313 |
that their semantic is preserved. |
314 |
|
315 |
@section Self-virtualization |
316 |
|
317 |
QEMU was conceived so that ultimately it can emulate itself. Althought |
318 |
it is not very useful, it is an important test to show the power of the |
319 |
emulator. |
320 |
|
321 |
Achieving self-virtualization is not easy because there may be address |
322 |
space conflicts. QEMU solves this problem by being an executable ELF |
323 |
shared object as the ld-linux.so ELF interpreter. That way, it can be |
324 |
relocated at load time. |
325 |
|
326 |
Since self-modifying code is not supported yet, QEMU cannot emulate |
327 |
itself in case of translation cache flush. This limitation will be |
328 |
suppressed soon. |
329 |
|
330 |
@section Bibliography |
331 |
|
332 |
@table @asis |
333 |
|
334 |
@item [1] |
335 |
@url{http://citeseer.nj.nec.com/piumarta98optimizing.html}, Optimizing |
336 |
direct threaded code by selective inlining (1998) by Ian Piumarta, Fabio |
337 |
Riccardi. |
338 |
|
339 |
@item [2] |
340 |
@url{http://developer.kde.org/~sewardj/}, Valgrind, an open-source |
341 |
memory debugger for x86-GNU/Linux, by Julian Seward. |
342 |
|
343 |
@item [3] |
344 |
@url{http://bochs.sourceforge.net/}, the Bochs IA-32 Emulator Project, |
345 |
by Kevin Lawton et al. |
346 |
|
347 |
@item [4] |
348 |
@url{http://www.cs.rose-hulman.edu/~donaldlf/em86/index.html}, the EM86 |
349 |
x86 emulator on Alpha-Linux. |
350 |
|
351 |
@item [5] |
352 |
@url{http://www.usenix.org/publications/library/proceedings/usenix-nt97/full_papers/chernoff/chernoff.pdf}, |
353 |
DIGITAL FX!32: Running 32-Bit x86 Applications on Alpha NT, by Anton |
354 |
Chernoff and Ray Hookway. |
355 |
|
356 |
@item [6] |
357 |
@url{http://www.willows.com/}, Windows API library emulation from |
358 |
Willows Software. |
359 |
|
360 |
@end table |
361 |
|
362 |
@chapter Regression Tests |
363 |
|
364 |
In the directory @file{tests/}, various interesting x86 testing programs |
365 |
are available. There are used for regression testing. |
366 |
|
367 |
@section @file{hello} |
368 |
|
369 |
Very simple statically linked x86 program, just to test QEMU during a |
370 |
port to a new host CPU. |
371 |
|
372 |
@section @file{test-i386} |
373 |
|
374 |
This program executes most of the 16 bit and 32 bit x86 instructions and |
375 |
generates a text output. It can be compared with the output obtained with |
376 |
a real CPU or another emulator. The target @code{make test} runs this |
377 |
program and a @code{diff} on the generated output. |
378 |
|
379 |
The Linux system call @code{modify_ldt()} is used to create x86 selectors |
380 |
to test some 16 bit addressing and 32 bit with segmentation cases. |
381 |
|
382 |
@section @file{testsig} |
383 |
|
384 |
This program tests various signal cases, including SIGFPE, SIGSEGV and |
385 |
SIGILL. |
386 |
|
387 |
@section @file{testclone} |
388 |
|
389 |
Tests the @code{clone()} system call (basic test). |
390 |
|
391 |
@section @file{testthread} |
392 |
|
393 |
Tests the glibc threads (more complicated than @code{clone()} because signals |
394 |
are also used). |
395 |
|
396 |
@section @file{sha1} |
397 |
|
398 |
It is a simple benchmark. Care must be taken to interpret the results |
399 |
because it mostly tests the ability of the virtual CPU to optimize the |
400 |
@code{rol} x86 instruction and the condition code computations. |
401 |
|
402 |
@section @file{runcom} |
403 |
|
404 |
A very simple MSDOS emulator to test the Linux vm86() system call |
405 |
emulation. The excellent 54 byte @file{pi_10.com} PI number calculator |
406 |
can be launched with it. @file{pi_10.com} was written by Bertram |
407 |
Felgenhauer (more information at @url{http://www.boo.net/~jasonp/pipage.html}). |