]>
Commit | Line | Data |
---|---|---|
386405f7 FB |
1 | \input texinfo @c -*- texinfo -*- |
2 | ||
322d0c66 | 3 | @settitle QEMU CPU Emulator Reference Documentation |
386405f7 FB |
4 | @titlepage |
5 | @sp 7 | |
322d0c66 | 6 | @center @titlefont{QEMU CPU Emulator Reference Documentation} |
386405f7 FB |
7 | @sp 3 |
8 | @end titlepage | |
9 | ||
10 | @chapter Introduction | |
11 | ||
322d0c66 | 12 | @section Features |
386405f7 | 13 | |
1eb20527 FB |
14 | QEMU is a FAST! processor emulator. By using dynamic translation it |
15 | achieves a reasonnable speed while being easy to port on new host | |
16 | CPUs. | |
17 | ||
18 | QEMU has two operating modes: | |
19 | @itemize | |
20 | @item User mode emulation. In this mode, QEMU can launch Linux processes | |
21 | compiled for one CPU on another CPU. Linux system calls are converted | |
22 | because of endianness and 32/64 bit mismatches. The Wine Windows API | |
23 | emulator (@url{http://www.winehq.org}) and the DOSEMU DOS emulator | |
24 | (@url{www.dosemu.org}) are the main targets for QEMU. | |
25 | ||
26 | @item Full system emulation. In this mode, QEMU emulates a full | |
27 | system, including a processor and various peripherials. Currently, it | |
28 | is only used to launch an x86 Linux kernel on an x86 Linux system. It | |
29 | enables easier testing and debugging of system code. It can also be | |
30 | used to provide virtual hosting of several virtual PCs on a single | |
31 | server. | |
32 | ||
33 | @end itemize | |
34 | ||
35 | As QEMU requires no host kernel patches to run, it is very safe and | |
36 | easy to use. | |
322d0c66 FB |
37 | |
38 | QEMU generic features: | |
386405f7 FB |
39 | |
40 | @itemize | |
41 | ||
1eb20527 FB |
42 | @item User space only or full system emulation. |
43 | ||
44 | @item Using dynamic translation to native code for reasonnable speed. | |
386405f7 | 45 | |
322d0c66 | 46 | @item Working on x86 and PowerPC hosts. Being tested on ARM, Sparc32, Alpha and S390. |
386405f7 | 47 | |
1eb20527 FB |
48 | @item Self-modifying code support. |
49 | ||
50 | @item Precise exception support. | |
386405f7 | 51 | |
1eb20527 FB |
52 | @item The virtual CPU is a library (@code{libqemu}) which can be used |
53 | in other projects. | |
54 | ||
55 | @end itemize | |
56 | ||
57 | QEMU user mode emulation features: | |
58 | @itemize | |
386405f7 FB |
59 | @item Generic Linux system call converter, including most ioctls. |
60 | ||
61 | @item clone() emulation using native CPU clone() to use Linux scheduler for threads. | |
62 | ||
322d0c66 | 63 | @item Accurate signal handling by remapping host signals to target signals. |
1eb20527 FB |
64 | @end itemize |
65 | @end itemize | |
df0f11a0 | 66 | |
1eb20527 FB |
67 | QEMU full system emulation features: |
68 | @itemize | |
69 | @item Using mmap() system calls to simulate the MMU | |
322d0c66 FB |
70 | @end itemize |
71 | ||
72 | @section x86 emulation | |
73 | ||
74 | QEMU x86 target features: | |
75 | ||
76 | @itemize | |
77 | ||
78 | @item The virtual x86 CPU supports 16 bit and 32 bit addressing with segmentation. | |
1eb20527 | 79 | LDT/GDT and IDT are emulated. VM86 mode is also supported to run DOSEMU. |
322d0c66 | 80 | |
1eb20527 | 81 | @item Support of host page sizes bigger than 4KB in user mode emulation. |
df0f11a0 FB |
82 | |
83 | @item QEMU can emulate itself on x86. | |
1eb87257 | 84 | |
386405f7 FB |
85 | @item An extensive Linux x86 CPU test program is included @file{tests/test-i386}. |
86 | It can be used to test other x86 virtual CPUs. | |
87 | ||
88 | @end itemize | |
89 | ||
df0f11a0 | 90 | Current QEMU limitations: |
386405f7 FB |
91 | |
92 | @itemize | |
93 | ||
386405f7 FB |
94 | @item No SSE/MMX support (yet). |
95 | ||
96 | @item No x86-64 support. | |
97 | ||
df0f11a0 | 98 | @item IPC syscalls are missing. |
386405f7 FB |
99 | |
100 | @item The x86 segment limits and access rights are not tested at every | |
1eb20527 | 101 | memory access. |
386405f7 FB |
102 | |
103 | @item On non x86 host CPUs, @code{double}s are used instead of the non standard | |
104 | 10 byte @code{long double}s of x86 for floating point emulation to get | |
105 | maximum performances. | |
106 | ||
1eb20527 FB |
107 | @item Full system emulation only works if no data are mapped above the virtual address |
108 | 0xc0000000 (yet). | |
109 | ||
110 | @item Some priviledged instructions or behaviors are missing. Only the ones | |
111 | needed for proper Linux kernel operation are emulated. | |
112 | ||
113 | @item No memory separation between the kernel and the user processes is done. | |
114 | It will be implemented very soon. | |
115 | ||
386405f7 FB |
116 | @end itemize |
117 | ||
322d0c66 FB |
118 | @section ARM emulation |
119 | ||
120 | @itemize | |
121 | ||
122 | @item ARM emulation can currently launch small programs while using the | |
123 | generic dynamic code generation architecture of QEMU. | |
124 | ||
125 | @item No FPU support (yet). | |
126 | ||
127 | @item No automatic regression testing (yet). | |
128 | ||
129 | @end itemize | |
130 | ||
1eb20527 | 131 | @chapter QEMU User space emulation invocation |
386405f7 | 132 | |
d691f669 FB |
133 | @section Quick Start |
134 | ||
322d0c66 FB |
135 | If you need to compile QEMU, please read the @file{README} which gives |
136 | the related information. | |
137 | ||
386405f7 | 138 | In order to launch a Linux process, QEMU needs the process executable |
d691f669 FB |
139 | itself and all the target (x86) dynamic libraries used by it. |
140 | ||
141 | @itemize | |
386405f7 | 142 | |
d691f669 FB |
143 | @item On x86, you can just try to launch any process by using the native |
144 | libraries: | |
386405f7 FB |
145 | |
146 | @example | |
d691f669 | 147 | qemu -L / /bin/ls |
386405f7 FB |
148 | @end example |
149 | ||
d691f669 FB |
150 | @code{-L /} tells that the x86 dynamic linker must be searched with a |
151 | @file{/} prefix. | |
386405f7 | 152 | |
1eb87257 FB |
153 | @item Since QEMU is also a linux process, you can launch qemu with qemu: |
154 | ||
155 | @example | |
156 | qemu -L / qemu -L / /bin/ls | |
157 | @end example | |
386405f7 | 158 | |
d691f669 | 159 | @item On non x86 CPUs, you need first to download at least an x86 glibc |
1eb87257 | 160 | (@file{qemu-XXX-i386-glibc21.tar.gz} on the QEMU web page). Ensure that |
644c433c FB |
161 | @code{LD_LIBRARY_PATH} is not set: |
162 | ||
163 | @example | |
164 | unset LD_LIBRARY_PATH | |
165 | @end example | |
166 | ||
167 | Then you can launch the precompiled @file{ls} x86 executable: | |
168 | ||
d691f669 | 169 | @example |
168485b7 FB |
170 | qemu /usr/local/qemu-i386/bin/ls-i386 |
171 | @end example | |
172 | You can look at @file{/usr/local/qemu-i386/bin/qemu-conf.sh} so that | |
173 | QEMU is automatically launched by the Linux kernel when you try to | |
174 | launch x86 executables. It requires the @code{binfmt_misc} module in the | |
175 | Linux kernel. | |
176 | ||
1eb87257 FB |
177 | @item The x86 version of QEMU is also included. You can try weird things such as: |
178 | @example | |
179 | qemu /usr/local/qemu-i386/bin/qemu-i386 /usr/local/qemu-i386/bin/ls-i386 | |
180 | @end example | |
181 | ||
168485b7 FB |
182 | @end itemize |
183 | ||
df0f11a0 | 184 | @section Wine launch |
168485b7 FB |
185 | |
186 | @itemize | |
187 | ||
188 | @item Ensure that you have a working QEMU with the x86 glibc | |
189 | distribution (see previous section). In order to verify it, you must be | |
190 | able to do: | |
191 | ||
192 | @example | |
193 | qemu /usr/local/qemu-i386/bin/ls-i386 | |
194 | @end example | |
195 | ||
fd429f2f | 196 | @item Download the binary x86 Wine install |
1eb87257 | 197 | (@file{qemu-XXX-i386-wine.tar.gz} on the QEMU web page). |
168485b7 | 198 | |
fd429f2f | 199 | @item Configure Wine on your account. Look at the provided script |
168485b7 FB |
200 | @file{/usr/local/qemu-i386/bin/wine-conf.sh}. Your previous |
201 | @code{$@{HOME@}/.wine} directory is saved to @code{$@{HOME@}/.wine.org}. | |
202 | ||
203 | @item Then you can try the example @file{putty.exe}: | |
204 | ||
205 | @example | |
206 | qemu /usr/local/qemu-i386/wine/bin/wine /usr/local/qemu-i386/wine/c/Program\ Files/putty.exe | |
386405f7 | 207 | @end example |
d691f669 FB |
208 | |
209 | @end itemize | |
210 | ||
211 | @section Command line options | |
212 | ||
213 | @example | |
214 | usage: qemu [-h] [-d] [-L path] [-s size] program [arguments...] | |
215 | @end example | |
216 | ||
df0f11a0 | 217 | @table @option |
d691f669 FB |
218 | @item -h |
219 | Print the help | |
d691f669 FB |
220 | @item -L path |
221 | Set the x86 elf interpreter prefix (default=/usr/local/qemu-i386) | |
222 | @item -s size | |
223 | Set the x86 stack size in bytes (default=524288) | |
224 | @end table | |
386405f7 | 225 | |
df0f11a0 FB |
226 | Debug options: |
227 | ||
228 | @table @option | |
229 | @item -d | |
230 | Activate log (logfile=/tmp/qemu.log) | |
231 | @item -p pagesize | |
232 | Act as if the host page size was 'pagesize' bytes | |
233 | @end table | |
234 | ||
1eb20527 FB |
235 | @chapter QEMU System emulator invocation |
236 | ||
237 | @section Quick Start | |
238 | ||
239 | This section explains how to launch a Linux kernel inside QEMU. | |
240 | ||
241 | @enumerate | |
242 | @item | |
243 | Download the archive @file{vl-test-xxx.tar.gz} containing a Linux kernel | |
244 | and an initrd (initial Ram Disk). The archive also contains a | |
245 | precompiled version of @file{vl}, the QEMU System emulator. | |
246 | ||
247 | @item Optional: If you want network support (for example to launch X11 examples), you | |
248 | must copy the script @file{vl-ifup} in @file{/etc} and configure | |
249 | properly @code{sudo} so that the command @code{ifconfig} contained in | |
250 | @file{vl-ifup} can be executed as root. You must verify that your host | |
251 | kernel supports the TUN/TAP network interfaces: the device | |
252 | @file{/dev/net/tun} must be present. | |
253 | ||
254 | When network is enabled, there is a virtual network connection between | |
255 | the host kernel and the emulated kernel. The emulated kernel is seen | |
256 | from the host kernel at IP address 172.20.0.2 and the host kernel is | |
257 | seen from the emulated kernel at IP address 172.20.0.1. | |
258 | ||
259 | @item Launch @code{vl.sh}. You should have the following output: | |
260 | ||
261 | @example | |
262 | > ./vl.sh | |
263 | connected to host network interface: tun0 | |
264 | Uncompressing Linux... Ok, booting the kernel. | |
265 | Linux version 2.4.20 (bellard@voyager) (gcc version 2.95.2 20000220 (Debian GNU/Linux)) #42 Wed Jun 25 14:16:12 CEST 2003 | |
266 | BIOS-provided physical RAM map: | |
267 | BIOS-88: 0000000000000000 - 000000000009f000 (usable) | |
268 | BIOS-88: 0000000000100000 - 0000000002000000 (usable) | |
269 | 32MB LOWMEM available. | |
270 | On node 0 totalpages: 8192 | |
271 | zone(0): 4096 pages. | |
272 | zone(1): 4096 pages. | |
273 | zone(2): 0 pages. | |
274 | Kernel command line: root=/dev/ram ramdisk_size=6144 | |
275 | Initializing CPU#0 | |
276 | Detected 501.785 MHz processor. | |
277 | Calibrating delay loop... 973.20 BogoMIPS | |
278 | Memory: 24776k/32768k available (725k kernel code, 7604k reserved, 151k data, 48k init, 0k highmem) | |
279 | Dentry cache hash table entries: 4096 (order: 3, 32768 bytes) | |
280 | Inode cache hash table entries: 2048 (order: 2, 16384 bytes) | |
281 | Mount-cache hash table entries: 512 (order: 0, 4096 bytes) | |
282 | Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes) | |
283 | Page-cache hash table entries: 8192 (order: 3, 32768 bytes) | |
284 | CPU: Intel Pentium Pro stepping 03 | |
285 | Checking 'hlt' instruction... OK. | |
286 | POSIX conformance testing by UNIFIX | |
287 | Linux NET4.0 for Linux 2.4 | |
288 | Based upon Swansea University Computer Society NET3.039 | |
289 | Initializing RT netlink socket | |
290 | apm: BIOS not found. | |
291 | Starting kswapd | |
292 | pty: 256 Unix98 ptys configured | |
293 | Serial driver version 5.05c (2001-07-08) with no serial options enabled | |
294 | ttyS00 at 0x03f8 (irq = 4) is a 16450 | |
295 | ne.c:v1.10 9/23/94 Donald Becker (becker@scyld.com) | |
296 | Last modified Nov 1, 2000 by Paul Gortmaker | |
297 | NE*000 ethercard probe at 0x300: 52 54 00 12 34 56 | |
298 | eth0: NE2000 found at 0x300, using IRQ 9. | |
299 | RAMDISK driver initialized: 16 RAM disks of 6144K size 1024 blocksize | |
300 | NET4: Linux TCP/IP 1.0 for NET4.0 | |
301 | IP Protocols: ICMP, UDP, TCP, IGMP | |
302 | IP: routing cache hash table of 512 buckets, 4Kbytes | |
303 | TCP: Hash tables configured (established 2048 bind 2048) | |
304 | NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. | |
305 | RAMDISK: ext2 filesystem found at block 0 | |
306 | RAMDISK: Loading 6144 blocks [1 disk] into ram disk... done. | |
307 | Freeing initrd memory: 6144k freed | |
308 | VFS: Mounted root (ext2 filesystem). | |
309 | Freeing unused kernel memory: 48k freed | |
310 | sh: can't access tty; job control turned off | |
311 | # | |
312 | @end example | |
313 | ||
314 | @item | |
315 | Then you can play with the kernel inside the virtual serial console. You | |
316 | can launch @code{ls} for example. Type @key{Ctrl-a h} to have an help | |
317 | about the keys you can type inside the virtual serial console. In | |
318 | particular @key{Ctrl-a b} is the Magic SysRq key. | |
319 | ||
320 | @item | |
321 | If the network is enabled, launch the script @file{/etc/linuxrc} in the | |
322 | emulator (don't forget the leading dot): | |
323 | @example | |
324 | . /etc/linuxrc | |
325 | @end example | |
326 | ||
327 | Then enable X11 connections on your PC from the emulated Linux: | |
328 | @example | |
329 | xhost +172.20.0.2 | |
330 | @end example | |
331 | ||
332 | You can now launch @file{xterm} or @file{xlogo} and verify that you have | |
333 | a real Virtual Linux system ! | |
334 | ||
335 | @end enumerate | |
336 | ||
337 | NOTE: the example initrd is a modified version of the one made by Kevin | |
338 | Lawton for the plex86 Project (@url{www.plex86.org}). | |
339 | ||
340 | @section Kernel Compilation | |
341 | ||
342 | You can use any Linux kernel within QEMU provided it is mapped at | |
343 | address 0x90000000 (the default is 0xc0000000). You must modify only two | |
344 | lines in the kernel source: | |
345 | ||
346 | In asm/page.h, replace | |
347 | @example | |
348 | #define __PAGE_OFFSET (0xc0000000) | |
349 | @end example | |
350 | by | |
351 | @example | |
352 | #define __PAGE_OFFSET (0x90000000) | |
353 | @end example | |
354 | ||
355 | And in arch/i386/vmlinux.lds, replace | |
356 | @example | |
357 | . = 0xc0000000 + 0x100000; | |
358 | @end example | |
359 | by | |
360 | @example | |
361 | . = 0x90000000 + 0x100000; | |
362 | @end example | |
363 | ||
364 | The file config-2.4.20 gives the configuration of the example kernel. | |
365 | ||
366 | Just type | |
367 | @example | |
368 | make bzImage | |
369 | @end example | |
370 | ||
371 | As you would do to make a real kernel. Then you can use with QEMU | |
372 | exactly the same kernel as you would boot on your PC (in | |
373 | @file{arch/i386/boot/bzImage}). | |
374 | ||
375 | @section PC Emulation | |
376 | ||
377 | QEMU emulates the following PC peripherials: | |
378 | ||
379 | @itemize | |
380 | @item | |
381 | PIC (interrupt controler) | |
382 | @item | |
383 | PIT (timers) | |
384 | @item | |
385 | CMOS memory | |
386 | @item | |
387 | Serial port (port=0x3f8, irq=4) | |
388 | @item | |
389 | NE2000 network adapter (port=0x300, irq=9) | |
390 | @item | |
391 | Dumb VGA (to print the @code{uncompressing Linux kernel} message) | |
392 | @end itemize | |
393 | ||
386405f7 FB |
394 | @chapter QEMU Internals |
395 | ||
396 | @section QEMU compared to other emulators | |
397 | ||
1eb20527 FB |
398 | Like bochs [3], QEMU emulates an x86 CPU. But QEMU is much faster than |
399 | bochs as it uses dynamic compilation and because it uses the host MMU to | |
400 | simulate the x86 MMU. The downside is that currently the emulation is | |
401 | not as accurate as bochs (for example, you cannot currently run Windows | |
402 | inside QEMU). | |
386405f7 FB |
403 | |
404 | Like Valgrind [2], QEMU does user space emulation and dynamic | |
405 | translation. Valgrind is mainly a memory debugger while QEMU has no | |
1eb20527 FB |
406 | support for it (QEMU could be used to detect out of bound memory |
407 | accesses as Valgrind, but it has no support to track uninitialised data | |
408 | as Valgrind does). Valgrind dynamic translator generates better code | |
409 | than QEMU (in particular it does register allocation) but it is closely | |
410 | tied to an x86 host and target and has no support for precise exception | |
411 | and system emulation. | |
412 | ||
413 | EM86 [4] is the closest project to user space QEMU (and QEMU still uses | |
414 | some of its code, in particular the ELF file loader). EM86 was limited | |
415 | to an alpha host and used a proprietary and slow interpreter (the | |
416 | interpreter part of the FX!32 Digital Win32 code translator [5]). | |
386405f7 | 417 | |
fd429f2f FB |
418 | TWIN [6] is a Windows API emulator like Wine. It is less accurate than |
419 | Wine but includes a protected mode x86 interpreter to launch x86 Windows | |
420 | executables. Such an approach as greater potential because most of the | |
421 | Windows API is executed natively but it is far more difficult to develop | |
422 | because all the data structures and function parameters exchanged | |
423 | between the API and the x86 code must be converted. | |
424 | ||
1eb20527 FB |
425 | User mode Linux [7] was the only solution before QEMU to launch a Linux |
426 | kernel as a process while not needing any host kernel patches. However, | |
427 | user mode Linux requires heavy kernel patches while QEMU accepts | |
428 | unpatched Linux kernels. It would be interesting to compare the | |
429 | performance of the two approaches. | |
430 | ||
431 | The new Plex86 [8] PC virtualizer is done in the same spirit as the QEMU | |
432 | system emulator. It requires a patched Linux kernel to work (you cannot | |
433 | launch the same kernel on your PC), but the patches are really small. As | |
434 | it is a PC virtualizer (no emulation is done except for some priveledged | |
435 | instructions), it has the potential of being faster than QEMU. The | |
436 | downside is that a complicated (and potentially unsafe) kernel patch is | |
437 | needed. | |
438 | ||
386405f7 FB |
439 | @section Portable dynamic translation |
440 | ||
441 | QEMU is a dynamic translator. When it first encounters a piece of code, | |
442 | it converts it to the host instruction set. Usually dynamic translators | |
322d0c66 | 443 | are very complicated and highly CPU dependent. QEMU uses some tricks |
386405f7 FB |
444 | which make it relatively easily portable and simple while achieving good |
445 | performances. | |
446 | ||
447 | The basic idea is to split every x86 instruction into fewer simpler | |
448 | instructions. Each simple instruction is implemented by a piece of C | |
449 | code (see @file{op-i386.c}). Then a compile time tool (@file{dyngen}) | |
450 | takes the corresponding object file (@file{op-i386.o}) to generate a | |
451 | dynamic code generator which concatenates the simple instructions to | |
452 | build a function (see @file{op-i386.h:dyngen_code()}). | |
453 | ||
454 | In essence, the process is similar to [1], but more work is done at | |
455 | compile time. | |
456 | ||
457 | A key idea to get optimal performances is that constant parameters can | |
458 | be passed to the simple operations. For that purpose, dummy ELF | |
459 | relocations are generated with gcc for each constant parameter. Then, | |
460 | the tool (@file{dyngen}) can locate the relocations and generate the | |
461 | appriopriate C code to resolve them when building the dynamic code. | |
462 | ||
463 | That way, QEMU is no more difficult to port than a dynamic linker. | |
464 | ||
465 | To go even faster, GCC static register variables are used to keep the | |
466 | state of the virtual CPU. | |
467 | ||
468 | @section Register allocation | |
469 | ||
470 | Since QEMU uses fixed simple instructions, no efficient register | |
471 | allocation can be done. However, because RISC CPUs have a lot of | |
472 | register, most of the virtual CPU state can be put in registers without | |
473 | doing complicated register allocation. | |
474 | ||
475 | @section Condition code optimisations | |
476 | ||
477 | Good CPU condition codes emulation (@code{EFLAGS} register on x86) is a | |
478 | critical point to get good performances. QEMU uses lazy condition code | |
479 | evaluation: instead of computing the condition codes after each x86 | |
fd429f2f | 480 | instruction, it just stores one operand (called @code{CC_SRC}), the |
386405f7 FB |
481 | result (called @code{CC_DST}) and the type of operation (called |
482 | @code{CC_OP}). | |
483 | ||
484 | @code{CC_OP} is almost never explicitely set in the generated code | |
485 | because it is known at translation time. | |
486 | ||
487 | In order to increase performances, a backward pass is performed on the | |
488 | generated simple instructions (see | |
489 | @code{translate-i386.c:optimize_flags()}). When it can be proved that | |
490 | the condition codes are not needed by the next instructions, no | |
491 | condition codes are computed at all. | |
492 | ||
fd429f2f | 493 | @section CPU state optimisations |
386405f7 FB |
494 | |
495 | The x86 CPU has many internal states which change the way it evaluates | |
496 | instructions. In order to achieve a good speed, the translation phase | |
497 | considers that some state information of the virtual x86 CPU cannot | |
498 | change in it. For example, if the SS, DS and ES segments have a zero | |
499 | base, then the translator does not even generate an addition for the | |
500 | segment base. | |
501 | ||
502 | [The FPU stack pointer register is not handled that way yet]. | |
503 | ||
504 | @section Translation cache | |
505 | ||
506 | A 2MByte cache holds the most recently used translations. For | |
507 | simplicity, it is completely flushed when it is full. A translation unit | |
508 | contains just a single basic block (a block of x86 instructions | |
509 | terminated by a jump or by a virtual CPU state change which the | |
510 | translator cannot deduce statically). | |
511 | ||
df0f11a0 FB |
512 | @section Direct block chaining |
513 | ||
514 | After each translated basic block is executed, QEMU uses the simulated | |
515 | Program Counter (PC) and other cpu state informations (such as the CS | |
516 | segment base value) to find the next basic block. | |
517 | ||
518 | In order to accelerate the most common cases where the new simulated PC | |
519 | is known, QEMU can patch a basic block so that it jumps directly to the | |
520 | next one. | |
521 | ||
522 | The most portable code uses an indirect jump. An indirect jump makes it | |
523 | easier to make the jump target modification atomic. On some | |
524 | architectures (such as PowerPC), the @code{JUMP} opcode is directly | |
525 | patched so that the block chaining has no overhead. | |
526 | ||
527 | @section Self-modifying code and translated code invalidation | |
528 | ||
529 | Self-modifying code is a special challenge in x86 emulation because no | |
530 | instruction cache invalidation is signaled by the application when code | |
531 | is modified. | |
532 | ||
533 | When translated code is generated for a basic block, the corresponding | |
534 | host page is write protected if it is not already read-only (with the | |
535 | system call @code{mprotect()}). Then, if a write access is done to the | |
536 | page, Linux raises a SEGV signal. QEMU then invalidates all the | |
537 | translated code in the page and enables write accesses to the page. | |
538 | ||
539 | Correct translated code invalidation is done efficiently by maintaining | |
540 | a linked list of every translated block contained in a given page. Other | |
541 | linked lists are also maintained to undo direct block chaining. | |
542 | ||
543 | Althought the overhead of doing @code{mprotect()} calls is important, | |
544 | most MSDOS programs can be emulated at reasonnable speed with QEMU and | |
545 | DOSEMU. | |
546 | ||
547 | Note that QEMU also invalidates pages of translated code when it detects | |
548 | that memory mappings are modified with @code{mmap()} or @code{munmap()}. | |
386405f7 FB |
549 | |
550 | @section Exception support | |
551 | ||
552 | longjmp() is used when an exception such as division by zero is | |
df0f11a0 | 553 | encountered. |
386405f7 | 554 | |
df0f11a0 FB |
555 | The host SIGSEGV and SIGBUS signal handlers are used to get invalid |
556 | memory accesses. The exact CPU state can be retrieved because all the | |
557 | x86 registers are stored in fixed host registers. The simulated program | |
558 | counter is found by retranslating the corresponding basic block and by | |
559 | looking where the host program counter was at the exception point. | |
560 | ||
561 | The virtual CPU cannot retrieve the exact @code{EFLAGS} register because | |
562 | in some cases it is not computed because of condition code | |
563 | optimisations. It is not a big concern because the emulated code can | |
564 | still be restarted in any cases. | |
386405f7 FB |
565 | |
566 | @section Linux system call translation | |
567 | ||
568 | QEMU includes a generic system call translator for Linux. It means that | |
569 | the parameters of the system calls can be converted to fix the | |
570 | endianness and 32/64 bit issues. The IOCTLs are converted with a generic | |
571 | type description system (see @file{ioctls.h} and @file{thunk.c}). | |
572 | ||
df0f11a0 FB |
573 | QEMU supports host CPUs which have pages bigger than 4KB. It records all |
574 | the mappings the process does and try to emulated the @code{mmap()} | |
575 | system calls in cases where the host @code{mmap()} call would fail | |
576 | because of bad page alignment. | |
577 | ||
386405f7 FB |
578 | @section Linux signals |
579 | ||
580 | Normal and real-time signals are queued along with their information | |
581 | (@code{siginfo_t}) as it is done in the Linux kernel. Then an interrupt | |
582 | request is done to the virtual CPU. When it is interrupted, one queued | |
583 | signal is handled by generating a stack frame in the virtual CPU as the | |
584 | Linux kernel does. The @code{sigreturn()} system call is emulated to return | |
585 | from the virtual signal handler. | |
586 | ||
587 | Some signals (such as SIGALRM) directly come from the host. Other | |
588 | signals are synthetized from the virtual CPU exceptions such as SIGFPE | |
589 | when a division by zero is done (see @code{main.c:cpu_loop()}). | |
590 | ||
591 | The blocked signal mask is still handled by the host Linux kernel so | |
592 | that most signal system calls can be redirected directly to the host | |
593 | Linux kernel. Only the @code{sigaction()} and @code{sigreturn()} system | |
594 | calls need to be fully emulated (see @file{signal.c}). | |
595 | ||
596 | @section clone() system call and threads | |
597 | ||
598 | The Linux clone() system call is usually used to create a thread. QEMU | |
599 | uses the host clone() system call so that real host threads are created | |
600 | for each emulated thread. One virtual CPU instance is created for each | |
601 | thread. | |
602 | ||
603 | The virtual x86 CPU atomic operations are emulated with a global lock so | |
604 | that their semantic is preserved. | |
605 | ||
df0f11a0 FB |
606 | Note that currently there are still some locking issues in QEMU. In |
607 | particular, the translated cache flush is not protected yet against | |
608 | reentrancy. | |
609 | ||
1eb87257 FB |
610 | @section Self-virtualization |
611 | ||
612 | QEMU was conceived so that ultimately it can emulate itself. Althought | |
613 | it is not very useful, it is an important test to show the power of the | |
614 | emulator. | |
615 | ||
616 | Achieving self-virtualization is not easy because there may be address | |
6cd9f35b FB |
617 | space conflicts. QEMU solves this problem by being an executable ELF |
618 | shared object as the ld-linux.so ELF interpreter. That way, it can be | |
619 | relocated at load time. | |
1eb87257 | 620 | |
1eb20527 FB |
621 | @section MMU emulation |
622 | ||
623 | For system emulation, QEMU uses the mmap() system call to emulate the | |
624 | target CPU MMU. It works as long the emulated OS does not use an area | |
625 | reserved by the host OS (such as the area above 0xc0000000 on x86 | |
626 | Linux). | |
627 | ||
628 | It is planned to add a slower but more precise MMU emulation | |
629 | with a software MMU. | |
630 | ||
386405f7 FB |
631 | @section Bibliography |
632 | ||
633 | @table @asis | |
634 | ||
635 | @item [1] | |
636 | @url{http://citeseer.nj.nec.com/piumarta98optimizing.html}, Optimizing | |
637 | direct threaded code by selective inlining (1998) by Ian Piumarta, Fabio | |
638 | Riccardi. | |
639 | ||
640 | @item [2] | |
641 | @url{http://developer.kde.org/~sewardj/}, Valgrind, an open-source | |
642 | memory debugger for x86-GNU/Linux, by Julian Seward. | |
643 | ||
644 | @item [3] | |
645 | @url{http://bochs.sourceforge.net/}, the Bochs IA-32 Emulator Project, | |
646 | by Kevin Lawton et al. | |
647 | ||
648 | @item [4] | |
649 | @url{http://www.cs.rose-hulman.edu/~donaldlf/em86/index.html}, the EM86 | |
650 | x86 emulator on Alpha-Linux. | |
651 | ||
652 | @item [5] | |
653 | @url{http://www.usenix.org/publications/library/proceedings/usenix-nt97/full_papers/chernoff/chernoff.pdf}, | |
654 | DIGITAL FX!32: Running 32-Bit x86 Applications on Alpha NT, by Anton | |
655 | Chernoff and Ray Hookway. | |
656 | ||
fd429f2f FB |
657 | @item [6] |
658 | @url{http://www.willows.com/}, Windows API library emulation from | |
659 | Willows Software. | |
660 | ||
1eb20527 FB |
661 | @item [7] |
662 | @url{http://user-mode-linux.sourceforge.net/}, | |
663 | The User-mode Linux Kernel. | |
664 | ||
665 | @item [8] | |
666 | @url{http://www.plex86.org/}, | |
667 | The new Plex86 project. | |
668 | ||
386405f7 FB |
669 | @end table |
670 | ||
671 | @chapter Regression Tests | |
672 | ||
322d0c66 | 673 | In the directory @file{tests/}, various interesting testing programs |
386405f7 FB |
674 | are available. There are used for regression testing. |
675 | ||
322d0c66 | 676 | @section @file{hello-i386} |
386405f7 FB |
677 | |
678 | Very simple statically linked x86 program, just to test QEMU during a | |
679 | port to a new host CPU. | |
680 | ||
322d0c66 FB |
681 | @section @file{hello-arm} |
682 | ||
683 | Very simple statically linked ARM program, just to test QEMU during a | |
684 | port to a new host CPU. | |
685 | ||
386405f7 FB |
686 | @section @file{test-i386} |
687 | ||
688 | This program executes most of the 16 bit and 32 bit x86 instructions and | |
689 | generates a text output. It can be compared with the output obtained with | |
690 | a real CPU or another emulator. The target @code{make test} runs this | |
691 | program and a @code{diff} on the generated output. | |
692 | ||
693 | The Linux system call @code{modify_ldt()} is used to create x86 selectors | |
694 | to test some 16 bit addressing and 32 bit with segmentation cases. | |
695 | ||
df0f11a0 | 696 | The Linux system call @code{vm86()} is used to test vm86 emulation. |
386405f7 | 697 | |
df0f11a0 FB |
698 | Various exceptions are raised to test most of the x86 user space |
699 | exception reporting. | |
386405f7 FB |
700 | |
701 | @section @file{sha1} | |
702 | ||
703 | It is a simple benchmark. Care must be taken to interpret the results | |
704 | because it mostly tests the ability of the virtual CPU to optimize the | |
705 | @code{rol} x86 instruction and the condition code computations. | |
706 |