]>
Commit | Line | Data |
---|---|---|
1f673135 | 1 | \input texinfo @c -*- texinfo -*- |
debc7065 FB |
2 | @c %**start of header |
3 | @setfilename qemu-tech.info | |
e080e785 SW |
4 | |
5 | @documentlanguage en | |
6 | @documentencoding UTF-8 | |
7 | ||
debc7065 FB |
8 | @settitle QEMU Internals |
9 | @exampleindent 0 | |
10 | @paragraphindent 0 | |
11 | @c %**end of header | |
1f673135 | 12 | |
a1a32b05 SW |
13 | @ifinfo |
14 | @direntry | |
15 | * QEMU Internals: (qemu-tech). The QEMU Emulator Internals. | |
16 | @end direntry | |
17 | @end ifinfo | |
18 | ||
1f673135 | 19 | @iftex |
1f673135 FB |
20 | @titlepage |
21 | @sp 7 | |
22 | @center @titlefont{QEMU Internals} | |
23 | @sp 3 | |
24 | @end titlepage | |
25 | @end iftex | |
26 | ||
debc7065 FB |
27 | @ifnottex |
28 | @node Top | |
29 | @top | |
30 | ||
31 | @menu | |
32 | * Introduction:: | |
33 | * QEMU Internals:: | |
34 | * Regression Tests:: | |
35 | * Index:: | |
36 | @end menu | |
37 | @end ifnottex | |
38 | ||
39 | @contents | |
40 | ||
41 | @node Introduction | |
1f673135 FB |
42 | @chapter Introduction |
43 | ||
debc7065 | 44 | @menu |
3aeaea65 MF |
45 | * intro_features:: Features |
46 | * intro_x86_emulation:: x86 and x86-64 emulation | |
47 | * intro_arm_emulation:: ARM emulation | |
48 | * intro_mips_emulation:: MIPS emulation | |
49 | * intro_ppc_emulation:: PowerPC emulation | |
50 | * intro_sparc_emulation:: Sparc32 and Sparc64 emulation | |
51 | * intro_xtensa_emulation:: Xtensa emulation | |
52 | * intro_other_emulation:: Other CPU emulation | |
debc7065 FB |
53 | @end menu |
54 | ||
55 | @node intro_features | |
1f673135 FB |
56 | @section Features |
57 | ||
58 | QEMU is a FAST! processor emulator using a portable dynamic | |
59 | translator. | |
60 | ||
61 | QEMU has two operating modes: | |
62 | ||
63 | @itemize @minus | |
64 | ||
5fafdf24 | 65 | @item |
998a0501 BS |
66 | Full system emulation. In this mode (full platform virtualization), |
67 | QEMU emulates a full system (usually a PC), including a processor and | |
68 | various peripherals. It can be used to launch several different | |
69 | Operating Systems at once without rebooting the host machine or to | |
70 | debug system code. | |
1f673135 | 71 | |
5fafdf24 | 72 | @item |
998a0501 BS |
73 | User mode emulation. In this mode (application level virtualization), |
74 | QEMU can launch processes compiled for one CPU on another CPU, however | |
75 | the Operating Systems must match. This can be used for example to ease | |
76 | cross-compilation and cross-debugging. | |
1f673135 FB |
77 | @end itemize |
78 | ||
79 | As QEMU requires no host kernel driver to run, it is very safe and | |
80 | easy to use. | |
81 | ||
82 | QEMU generic features: | |
83 | ||
5fafdf24 | 84 | @itemize |
1f673135 FB |
85 | |
86 | @item User space only or full system emulation. | |
87 | ||
debc7065 | 88 | @item Using dynamic translation to native code for reasonable speed. |
1f673135 | 89 | |
998a0501 BS |
90 | @item |
91 | Working on x86, x86_64 and PowerPC32/64 hosts. Being tested on ARM, | |
92 | HPPA, Sparc32 and Sparc64. Previous versions had some support for | |
93 | Alpha and S390 hosts, but TCG (see below) doesn't support those yet. | |
1f673135 FB |
94 | |
95 | @item Self-modifying code support. | |
96 | ||
97 | @item Precise exceptions support. | |
98 | ||
998a0501 BS |
99 | @item |
100 | Floating point library supporting both full software emulation and | |
101 | native host FPU instructions. | |
102 | ||
1f673135 FB |
103 | @end itemize |
104 | ||
105 | QEMU user mode emulation features: | |
5fafdf24 | 106 | @itemize |
1f673135 FB |
107 | @item Generic Linux system call converter, including most ioctls. |
108 | ||
109 | @item clone() emulation using native CPU clone() to use Linux scheduler for threads. | |
110 | ||
5fafdf24 | 111 | @item Accurate signal handling by remapping host signals to target signals. |
1f673135 | 112 | @end itemize |
1f673135 | 113 | |
998a0501 | 114 | Linux user emulator (Linux host only) can be used to launch the Wine |
0adb1246 | 115 | Windows API emulator (@url{http://www.winehq.org}). A BSD user emulator for BSD |
998a0501 BS |
116 | hosts is under development. It would also be possible to develop a |
117 | similar user emulator for Solaris. | |
118 | ||
1f673135 | 119 | QEMU full system emulation features: |
5fafdf24 | 120 | @itemize |
998a0501 BS |
121 | @item |
122 | QEMU uses a full software MMU for maximum portability. | |
123 | ||
124 | @item | |
4a1418e0 AL |
125 | QEMU can optionally use an in-kernel accelerator, like kvm. The accelerators |
126 | execute some of the guest code natively, while | |
998a0501 BS |
127 | continuing to emulate the rest of the machine. |
128 | ||
129 | @item | |
130 | Various hardware devices can be emulated and in some cases, host | |
131 | devices (e.g. serial and parallel ports, USB, drives) can be used | |
132 | transparently by the guest Operating System. Host device passthrough | |
133 | can be used for talking to external physical peripherals (e.g. a | |
134 | webcam, modem or tape drive). | |
135 | ||
136 | @item | |
137 | Symmetric multiprocessing (SMP) even on a host with a single CPU. On a | |
138 | SMP host system, QEMU can use only one CPU fully due to difficulty in | |
139 | implementing atomic memory accesses efficiently. | |
140 | ||
1f673135 FB |
141 | @end itemize |
142 | ||
debc7065 | 143 | @node intro_x86_emulation |
998a0501 | 144 | @section x86 and x86-64 emulation |
1f673135 FB |
145 | |
146 | QEMU x86 target features: | |
147 | ||
5fafdf24 | 148 | @itemize |
1f673135 | 149 | |
5fafdf24 | 150 | @item The virtual x86 CPU supports 16 bit and 32 bit addressing with segmentation. |
998a0501 BS |
151 | LDT/GDT and IDT are emulated. VM86 mode is also supported to run |
152 | DOSEMU. There is some support for MMX/3DNow!, SSE, SSE2, SSE3, SSSE3, | |
153 | and SSE4 as well as x86-64 SVM. | |
1f673135 FB |
154 | |
155 | @item Support of host page sizes bigger than 4KB in user mode emulation. | |
156 | ||
157 | @item QEMU can emulate itself on x86. | |
158 | ||
5fafdf24 | 159 | @item An extensive Linux x86 CPU test program is included @file{tests/test-i386}. |
1f673135 FB |
160 | It can be used to test other x86 virtual CPUs. |
161 | ||
162 | @end itemize | |
163 | ||
164 | Current QEMU limitations: | |
165 | ||
5fafdf24 | 166 | @itemize |
1f673135 | 167 | |
998a0501 | 168 | @item Limited x86-64 support. |
1f673135 FB |
169 | |
170 | @item IPC syscalls are missing. | |
171 | ||
5fafdf24 | 172 | @item The x86 segment limits and access rights are not tested at every |
1f673135 FB |
173 | memory access (yet). Hopefully, very few OSes seem to rely on that for |
174 | normal use. | |
175 | ||
1f673135 FB |
176 | @end itemize |
177 | ||
debc7065 | 178 | @node intro_arm_emulation |
1f673135 FB |
179 | @section ARM emulation |
180 | ||
181 | @itemize | |
182 | ||
183 | @item Full ARM 7 user emulation. | |
184 | ||
185 | @item NWFPE FPU support included in user Linux emulation. | |
186 | ||
187 | @item Can run most ARM Linux binaries. | |
188 | ||
189 | @end itemize | |
190 | ||
24d4de45 TS |
191 | @node intro_mips_emulation |
192 | @section MIPS emulation | |
193 | ||
194 | @itemize | |
195 | ||
196 | @item The system emulation allows full MIPS32/MIPS64 Release 2 emulation, | |
197 | including privileged instructions, FPU and MMU, in both little and big | |
198 | endian modes. | |
199 | ||
200 | @item The Linux userland emulation can run many 32 bit MIPS Linux binaries. | |
201 | ||
202 | @end itemize | |
203 | ||
204 | Current QEMU limitations: | |
205 | ||
206 | @itemize | |
207 | ||
208 | @item Self-modifying code is not always handled correctly. | |
209 | ||
210 | @item 64 bit userland emulation is not implemented. | |
211 | ||
212 | @item The system emulation is not complete enough to run real firmware. | |
213 | ||
b1f45238 TS |
214 | @item The watchpoint debug facility is not implemented. |
215 | ||
24d4de45 TS |
216 | @end itemize |
217 | ||
debc7065 | 218 | @node intro_ppc_emulation |
1f673135 FB |
219 | @section PowerPC emulation |
220 | ||
221 | @itemize | |
222 | ||
5fafdf24 | 223 | @item Full PowerPC 32 bit emulation, including privileged instructions, |
1f673135 FB |
224 | FPU and MMU. |
225 | ||
226 | @item Can run most PowerPC Linux binaries. | |
227 | ||
228 | @end itemize | |
229 | ||
debc7065 | 230 | @node intro_sparc_emulation |
998a0501 | 231 | @section Sparc32 and Sparc64 emulation |
1f673135 FB |
232 | |
233 | @itemize | |
234 | ||
f6b647cd | 235 | @item Full SPARC V8 emulation, including privileged |
3475187d | 236 | instructions, FPU and MMU. SPARC V9 emulation includes most privileged |
a785e42e | 237 | and VIS instructions, FPU and I/D MMU. Alignment is fully enforced. |
1f673135 | 238 | |
a785e42e BS |
239 | @item Can run most 32-bit SPARC Linux binaries, SPARC32PLUS Linux binaries and |
240 | some 64-bit SPARC Linux binaries. | |
3475187d FB |
241 | |
242 | @end itemize | |
243 | ||
244 | Current QEMU limitations: | |
245 | ||
5fafdf24 | 246 | @itemize |
3475187d | 247 | |
3475187d FB |
248 | @item IPC syscalls are missing. |
249 | ||
1f587329 | 250 | @item Floating point exception support is buggy. |
3475187d FB |
251 | |
252 | @item Atomic instructions are not correctly implemented. | |
253 | ||
998a0501 BS |
254 | @item There are still some problems with Sparc64 emulators. |
255 | ||
256 | @end itemize | |
257 | ||
3aeaea65 MF |
258 | @node intro_xtensa_emulation |
259 | @section Xtensa emulation | |
260 | ||
261 | @itemize | |
262 | ||
263 | @item Core Xtensa ISA emulation, including most options: code density, | |
264 | loop, extended L32R, 16- and 32-bit multiplication, 32-bit division, | |
044d003d MF |
265 | MAC16, miscellaneous operations, boolean, FP coprocessor, coprocessor |
266 | context, debug, multiprocessor synchronization, | |
3aeaea65 MF |
267 | conditional store, exceptions, relocatable vectors, unaligned exception, |
268 | interrupts (including high priority and timer), hardware alignment, | |
269 | region protection, region translation, MMU, windowed registers, thread | |
270 | pointer, processor ID. | |
271 | ||
044d003d MF |
272 | @item Not implemented options: data/instruction cache (including cache |
273 | prefetch and locking), XLMI, processor interface. Also options not | |
274 | covered by the core ISA (e.g. FLIX, wide branches) are not implemented. | |
3aeaea65 MF |
275 | |
276 | @item Can run most Xtensa Linux binaries. | |
277 | ||
278 | @item New core configuration that requires no additional instructions | |
279 | may be created from overlay with minimal amount of hand-written code. | |
280 | ||
281 | @end itemize | |
282 | ||
998a0501 BS |
283 | @node intro_other_emulation |
284 | @section Other CPU emulation | |
1f673135 | 285 | |
998a0501 BS |
286 | In addition to the above, QEMU supports emulation of other CPUs with |
287 | varying levels of success. These are: | |
288 | ||
289 | @itemize | |
290 | ||
291 | @item | |
292 | Alpha | |
293 | @item | |
294 | CRIS | |
295 | @item | |
296 | M68k | |
297 | @item | |
298 | SH4 | |
1f673135 FB |
299 | @end itemize |
300 | ||
debc7065 | 301 | @node QEMU Internals |
1f673135 FB |
302 | @chapter QEMU Internals |
303 | ||
debc7065 FB |
304 | @menu |
305 | * QEMU compared to other emulators:: | |
306 | * Portable dynamic translation:: | |
debc7065 FB |
307 | * Condition code optimisations:: |
308 | * CPU state optimisations:: | |
309 | * Translation cache:: | |
310 | * Direct block chaining:: | |
311 | * Self-modifying code and translated code invalidation:: | |
312 | * Exception support:: | |
313 | * MMU emulation:: | |
998a0501 | 314 | * Device emulation:: |
debc7065 FB |
315 | * Hardware interrupts:: |
316 | * User emulation specific details:: | |
317 | * Bibliography:: | |
318 | @end menu | |
319 | ||
320 | @node QEMU compared to other emulators | |
1f673135 FB |
321 | @section QEMU compared to other emulators |
322 | ||
323 | Like bochs [3], QEMU emulates an x86 CPU. But QEMU is much faster than | |
324 | bochs as it uses dynamic compilation. Bochs is closely tied to x86 PC | |
325 | emulation while QEMU can emulate several processors. | |
326 | ||
327 | Like Valgrind [2], QEMU does user space emulation and dynamic | |
328 | translation. Valgrind is mainly a memory debugger while QEMU has no | |
329 | support for it (QEMU could be used to detect out of bound memory | |
330 | accesses as Valgrind, but it has no support to track uninitialised data | |
331 | as Valgrind does). The Valgrind dynamic translator generates better code | |
332 | than QEMU (in particular it does register allocation) but it is closely | |
333 | tied to an x86 host and target and has no support for precise exceptions | |
334 | and system emulation. | |
335 | ||
336 | EM86 [4] is the closest project to user space QEMU (and QEMU still uses | |
337 | some of its code, in particular the ELF file loader). EM86 was limited | |
338 | to an alpha host and used a proprietary and slow interpreter (the | |
339 | interpreter part of the FX!32 Digital Win32 code translator [5]). | |
340 | ||
341 | TWIN [6] is a Windows API emulator like Wine. It is less accurate than | |
342 | Wine but includes a protected mode x86 interpreter to launch x86 Windows | |
36d54d15 | 343 | executables. Such an approach has greater potential because most of the |
1f673135 FB |
344 | Windows API is executed natively but it is far more difficult to develop |
345 | because all the data structures and function parameters exchanged | |
346 | between the API and the x86 code must be converted. | |
347 | ||
348 | User mode Linux [7] was the only solution before QEMU to launch a | |
349 | Linux kernel as a process while not needing any host kernel | |
350 | patches. However, user mode Linux requires heavy kernel patches while | |
351 | QEMU accepts unpatched Linux kernels. The price to pay is that QEMU is | |
352 | slower. | |
353 | ||
998a0501 BS |
354 | The Plex86 [8] PC virtualizer is done in the same spirit as the now |
355 | obsolete qemu-fast system emulator. It requires a patched Linux kernel | |
356 | to work (you cannot launch the same kernel on your PC), but the | |
357 | patches are really small. As it is a PC virtualizer (no emulation is | |
358 | done except for some privileged instructions), it has the potential of | |
359 | being faster than QEMU. The downside is that a complicated (and | |
360 | potentially unsafe) host kernel patch is needed. | |
1f673135 FB |
361 | |
362 | The commercial PC Virtualizers (VMWare [9], VirtualPC [10], TwoOStwo | |
363 | [11]) are faster than QEMU, but they all need specific, proprietary | |
364 | and potentially unsafe host drivers. Moreover, they are unable to | |
365 | provide cycle exact simulation as an emulator can. | |
366 | ||
998a0501 BS |
367 | VirtualBox [12], Xen [13] and KVM [14] are based on QEMU. QEMU-SystemC |
368 | [15] uses QEMU to simulate a system where some hardware devices are | |
369 | developed in SystemC. | |
370 | ||
debc7065 | 371 | @node Portable dynamic translation |
1f673135 FB |
372 | @section Portable dynamic translation |
373 | ||
374 | QEMU is a dynamic translator. When it first encounters a piece of code, | |
375 | it converts it to the host instruction set. Usually dynamic translators | |
376 | are very complicated and highly CPU dependent. QEMU uses some tricks | |
377 | which make it relatively easily portable and simple while achieving good | |
378 | performances. | |
379 | ||
998a0501 BS |
380 | After the release of version 0.9.1, QEMU switched to a new method of |
381 | generating code, Tiny Code Generator or TCG. TCG relaxes the | |
382 | dependency on the exact version of the compiler used. The basic idea | |
383 | is to split every target instruction into a couple of RISC-like TCG | |
384 | ops (see @code{target-i386/translate.c}). Some optimizations can be | |
385 | performed at this stage, including liveness analysis and trivial | |
386 | constant expression evaluation. TCG ops are then implemented in the | |
387 | host CPU back end, also known as TCG target (see | |
388 | @code{tcg/i386/tcg-target.c}). For more information, please take a | |
389 | look at @code{tcg/README}. | |
1f673135 | 390 | |
debc7065 | 391 | @node Condition code optimisations |
1f673135 FB |
392 | @section Condition code optimisations |
393 | ||
998a0501 BS |
394 | Lazy evaluation of CPU condition codes (@code{EFLAGS} register on x86) |
395 | is important for CPUs where every instruction sets the condition | |
396 | codes. It tends to be less important on conventional RISC systems | |
f0f26a06 BS |
397 | where condition codes are only updated when explicitly requested. On |
398 | Sparc64, costly update of both 32 and 64 bit condition codes can be | |
399 | avoided with lazy evaluation. | |
998a0501 BS |
400 | |
401 | Instead of computing the condition codes after each x86 instruction, | |
402 | QEMU just stores one operand (called @code{CC_SRC}), the result | |
403 | (called @code{CC_DST}) and the type of operation (called | |
404 | @code{CC_OP}). When the condition codes are needed, the condition | |
405 | codes can be calculated using this information. In addition, an | |
406 | optimized calculation can be performed for some instruction types like | |
407 | conditional branches. | |
1f673135 | 408 | |
1235fc06 | 409 | @code{CC_OP} is almost never explicitly set in the generated code |
1f673135 FB |
410 | because it is known at translation time. |
411 | ||
f0f26a06 BS |
412 | The lazy condition code evaluation is used on x86, m68k, cris and |
413 | Sparc. ARM uses a simplified variant for the N and Z flags. | |
1f673135 | 414 | |
debc7065 | 415 | @node CPU state optimisations |
1f673135 FB |
416 | @section CPU state optimisations |
417 | ||
998a0501 BS |
418 | The target CPUs have many internal states which change the way it |
419 | evaluates instructions. In order to achieve a good speed, the | |
420 | translation phase considers that some state information of the virtual | |
421 | CPU cannot change in it. The state is recorded in the Translation | |
422 | Block (TB). If the state changes (e.g. privilege level), a new TB will | |
423 | be generated and the previous TB won't be used anymore until the state | |
424 | matches the state recorded in the previous TB. For example, if the SS, | |
425 | DS and ES segments have a zero base, then the translator does not even | |
426 | generate an addition for the segment base. | |
1f673135 FB |
427 | |
428 | [The FPU stack pointer register is not handled that way yet]. | |
429 | ||
debc7065 | 430 | @node Translation cache |
1f673135 FB |
431 | @section Translation cache |
432 | ||
27c8efcb | 433 | A 32 MByte cache holds the most recently used translations. For |
1f673135 FB |
434 | simplicity, it is completely flushed when it is full. A translation unit |
435 | contains just a single basic block (a block of x86 instructions | |
436 | terminated by a jump or by a virtual CPU state change which the | |
437 | translator cannot deduce statically). | |
438 | ||
debc7065 | 439 | @node Direct block chaining |
1f673135 FB |
440 | @section Direct block chaining |
441 | ||
442 | After each translated basic block is executed, QEMU uses the simulated | |
443 | Program Counter (PC) and other cpu state informations (such as the CS | |
444 | segment base value) to find the next basic block. | |
445 | ||
446 | In order to accelerate the most common cases where the new simulated PC | |
447 | is known, QEMU can patch a basic block so that it jumps directly to the | |
448 | next one. | |
449 | ||
450 | The most portable code uses an indirect jump. An indirect jump makes | |
451 | it easier to make the jump target modification atomic. On some host | |
452 | architectures (such as x86 or PowerPC), the @code{JUMP} opcode is | |
453 | directly patched so that the block chaining has no overhead. | |
454 | ||
debc7065 | 455 | @node Self-modifying code and translated code invalidation |
1f673135 FB |
456 | @section Self-modifying code and translated code invalidation |
457 | ||
458 | Self-modifying code is a special challenge in x86 emulation because no | |
459 | instruction cache invalidation is signaled by the application when code | |
460 | is modified. | |
461 | ||
462 | When translated code is generated for a basic block, the corresponding | |
998a0501 BS |
463 | host page is write protected if it is not already read-only. Then, if |
464 | a write access is done to the page, Linux raises a SEGV signal. QEMU | |
465 | then invalidates all the translated code in the page and enables write | |
466 | accesses to the page. | |
1f673135 FB |
467 | |
468 | Correct translated code invalidation is done efficiently by maintaining | |
469 | a linked list of every translated block contained in a given page. Other | |
5fafdf24 | 470 | linked lists are also maintained to undo direct block chaining. |
1f673135 | 471 | |
998a0501 BS |
472 | On RISC targets, correctly written software uses memory barriers and |
473 | cache flushes, so some of the protection above would not be | |
474 | necessary. However, QEMU still requires that the generated code always | |
475 | matches the target instructions in memory in order to handle | |
476 | exceptions correctly. | |
1f673135 | 477 | |
debc7065 | 478 | @node Exception support |
1f673135 FB |
479 | @section Exception support |
480 | ||
481 | longjmp() is used when an exception such as division by zero is | |
5fafdf24 | 482 | encountered. |
1f673135 FB |
483 | |
484 | The host SIGSEGV and SIGBUS signal handlers are used to get invalid | |
998a0501 BS |
485 | memory accesses. The simulated program counter is found by |
486 | retranslating the corresponding basic block and by looking where the | |
487 | host program counter was at the exception point. | |
1f673135 FB |
488 | |
489 | The virtual CPU cannot retrieve the exact @code{EFLAGS} register because | |
490 | in some cases it is not computed because of condition code | |
491 | optimisations. It is not a big concern because the emulated code can | |
492 | still be restarted in any cases. | |
493 | ||
debc7065 | 494 | @node MMU emulation |
1f673135 FB |
495 | @section MMU emulation |
496 | ||
998a0501 BS |
497 | For system emulation QEMU supports a soft MMU. In that mode, the MMU |
498 | virtual to physical address translation is done at every memory | |
499 | access. QEMU uses an address translation cache to speed up the | |
500 | translation. | |
1f673135 FB |
501 | |
502 | In order to avoid flushing the translated code each time the MMU | |
503 | mappings change, QEMU uses a physically indexed translation cache. It | |
5fafdf24 | 504 | means that each basic block is indexed with its physical address. |
1f673135 FB |
505 | |
506 | When MMU mappings change, only the chaining of the basic blocks is | |
507 | reset (i.e. a basic block can no longer jump directly to another one). | |
508 | ||
998a0501 BS |
509 | @node Device emulation |
510 | @section Device emulation | |
511 | ||
512 | Systems emulated by QEMU are organized by boards. At initialization | |
513 | phase, each board instantiates a number of CPUs, devices, RAM and | |
514 | ROM. Each device in turn can assign I/O ports or memory areas (for | |
515 | MMIO) to its handlers. When the emulation starts, an access to the | |
516 | ports or MMIO memory areas assigned to the device causes the | |
517 | corresponding handler to be called. | |
518 | ||
519 | RAM and ROM are handled more optimally, only the offset to the host | |
520 | memory needs to be added to the guest address. | |
521 | ||
522 | The video RAM of VGA and other display cards is special: it can be | |
523 | read or written directly like RAM, but write accesses cause the memory | |
524 | to be marked with VGA_DIRTY flag as well. | |
525 | ||
526 | QEMU supports some device classes like serial and parallel ports, USB, | |
527 | drives and network devices, by providing APIs for easier connection to | |
528 | the generic, higher level implementations. The API hides the | |
529 | implementation details from the devices, like native device use or | |
530 | advanced block device formats like QCOW. | |
531 | ||
532 | Usually the devices implement a reset method and register support for | |
533 | saving and loading of the device state. The devices can also use | |
534 | timers, especially together with the use of bottom halves (BHs). | |
535 | ||
debc7065 | 536 | @node Hardware interrupts |
1f673135 FB |
537 | @section Hardware interrupts |
538 | ||
e1b4382c | 539 | In order to be faster, QEMU does not check at every basic block if a |
e8dc0938 | 540 | hardware interrupt is pending. Instead, the user must asynchronously |
1f673135 FB |
541 | call a specific function to tell that an interrupt is pending. This |
542 | function resets the chaining of the currently executing basic | |
543 | block. It ensures that the execution will return soon in the main loop | |
544 | of the CPU emulator. Then the main loop can test if the interrupt is | |
545 | pending and handle it. | |
546 | ||
debc7065 | 547 | @node User emulation specific details |
1f673135 FB |
548 | @section User emulation specific details |
549 | ||
550 | @subsection Linux system call translation | |
551 | ||
552 | QEMU includes a generic system call translator for Linux. It means that | |
553 | the parameters of the system calls can be converted to fix the | |
554 | endianness and 32/64 bit issues. The IOCTLs are converted with a generic | |
555 | type description system (see @file{ioctls.h} and @file{thunk.c}). | |
556 | ||
557 | QEMU supports host CPUs which have pages bigger than 4KB. It records all | |
558 | the mappings the process does and try to emulated the @code{mmap()} | |
559 | system calls in cases where the host @code{mmap()} call would fail | |
560 | because of bad page alignment. | |
561 | ||
562 | @subsection Linux signals | |
563 | ||
564 | Normal and real-time signals are queued along with their information | |
565 | (@code{siginfo_t}) as it is done in the Linux kernel. Then an interrupt | |
566 | request is done to the virtual CPU. When it is interrupted, one queued | |
567 | signal is handled by generating a stack frame in the virtual CPU as the | |
568 | Linux kernel does. The @code{sigreturn()} system call is emulated to return | |
569 | from the virtual signal handler. | |
570 | ||
571 | Some signals (such as SIGALRM) directly come from the host. Other | |
e8dc0938 | 572 | signals are synthesized from the virtual CPU exceptions such as SIGFPE |
1f673135 FB |
573 | when a division by zero is done (see @code{main.c:cpu_loop()}). |
574 | ||
575 | The blocked signal mask is still handled by the host Linux kernel so | |
576 | that most signal system calls can be redirected directly to the host | |
577 | Linux kernel. Only the @code{sigaction()} and @code{sigreturn()} system | |
578 | calls need to be fully emulated (see @file{signal.c}). | |
579 | ||
580 | @subsection clone() system call and threads | |
581 | ||
582 | The Linux clone() system call is usually used to create a thread. QEMU | |
583 | uses the host clone() system call so that real host threads are created | |
584 | for each emulated thread. One virtual CPU instance is created for each | |
585 | thread. | |
586 | ||
587 | The virtual x86 CPU atomic operations are emulated with a global lock so | |
588 | that their semantic is preserved. | |
589 | ||
590 | Note that currently there are still some locking issues in QEMU. In | |
591 | particular, the translated cache flush is not protected yet against | |
592 | reentrancy. | |
593 | ||
594 | @subsection Self-virtualization | |
595 | ||
596 | QEMU was conceived so that ultimately it can emulate itself. Although | |
597 | it is not very useful, it is an important test to show the power of the | |
598 | emulator. | |
599 | ||
600 | Achieving self-virtualization is not easy because there may be address | |
998a0501 BS |
601 | space conflicts. QEMU user emulators solve this problem by being an |
602 | executable ELF shared object as the ld-linux.so ELF interpreter. That | |
603 | way, it can be relocated at load time. | |
1f673135 | 604 | |
debc7065 | 605 | @node Bibliography |
1f673135 FB |
606 | @section Bibliography |
607 | ||
608 | @table @asis | |
609 | ||
5fafdf24 | 610 | @item [1] |
1f673135 FB |
611 | @url{http://citeseer.nj.nec.com/piumarta98optimizing.html}, Optimizing |
612 | direct threaded code by selective inlining (1998) by Ian Piumarta, Fabio | |
613 | Riccardi. | |
614 | ||
615 | @item [2] | |
616 | @url{http://developer.kde.org/~sewardj/}, Valgrind, an open-source | |
617 | memory debugger for x86-GNU/Linux, by Julian Seward. | |
618 | ||
619 | @item [3] | |
620 | @url{http://bochs.sourceforge.net/}, the Bochs IA-32 Emulator Project, | |
621 | by Kevin Lawton et al. | |
622 | ||
623 | @item [4] | |
624 | @url{http://www.cs.rose-hulman.edu/~donaldlf/em86/index.html}, the EM86 | |
625 | x86 emulator on Alpha-Linux. | |
626 | ||
627 | @item [5] | |
debc7065 | 628 | @url{http://www.usenix.org/publications/library/proceedings/usenix-nt97/@/full_papers/chernoff/chernoff.pdf}, |
1f673135 FB |
629 | DIGITAL FX!32: Running 32-Bit x86 Applications on Alpha NT, by Anton |
630 | Chernoff and Ray Hookway. | |
631 | ||
632 | @item [6] | |
633 | @url{http://www.willows.com/}, Windows API library emulation from | |
634 | Willows Software. | |
635 | ||
636 | @item [7] | |
5fafdf24 | 637 | @url{http://user-mode-linux.sourceforge.net/}, |
1f673135 FB |
638 | The User-mode Linux Kernel. |
639 | ||
640 | @item [8] | |
5fafdf24 | 641 | @url{http://www.plex86.org/}, |
1f673135 FB |
642 | The new Plex86 project. |
643 | ||
644 | @item [9] | |
5fafdf24 | 645 | @url{http://www.vmware.com/}, |
1f673135 FB |
646 | The VMWare PC virtualizer. |
647 | ||
648 | @item [10] | |
5fafdf24 | 649 | @url{http://www.microsoft.com/windowsxp/virtualpc/}, |
1f673135 FB |
650 | The VirtualPC PC virtualizer. |
651 | ||
652 | @item [11] | |
5fafdf24 | 653 | @url{http://www.twoostwo.org/}, |
1f673135 FB |
654 | The TwoOStwo PC virtualizer. |
655 | ||
998a0501 BS |
656 | @item [12] |
657 | @url{http://virtualbox.org/}, | |
658 | The VirtualBox PC virtualizer. | |
659 | ||
660 | @item [13] | |
661 | @url{http://www.xen.org/}, | |
662 | The Xen hypervisor. | |
663 | ||
664 | @item [14] | |
665 | @url{http://kvm.qumranet.com/kvmwiki/Front_Page}, | |
666 | Kernel Based Virtual Machine (KVM). | |
667 | ||
668 | @item [15] | |
669 | @url{http://www.greensocs.com/projects/QEMUSystemC}, | |
670 | QEMU-SystemC, a hardware co-simulator. | |
671 | ||
1f673135 FB |
672 | @end table |
673 | ||
debc7065 | 674 | @node Regression Tests |
1f673135 FB |
675 | @chapter Regression Tests |
676 | ||
677 | In the directory @file{tests/}, various interesting testing programs | |
b1f45238 | 678 | are available. They are used for regression testing. |
1f673135 | 679 | |
debc7065 FB |
680 | @menu |
681 | * test-i386:: | |
682 | * linux-test:: | |
debc7065 FB |
683 | @end menu |
684 | ||
685 | @node test-i386 | |
1f673135 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 | ||
696 | The Linux system call @code{vm86()} is used to test vm86 emulation. | |
697 | ||
698 | Various exceptions are raised to test most of the x86 user space | |
699 | exception reporting. | |
700 | ||
debc7065 | 701 | @node linux-test |
1f673135 FB |
702 | @section @file{linux-test} |
703 | ||
704 | This program tests various Linux system calls. It is used to verify | |
705 | that the system call parameters are correctly converted between target | |
706 | and host CPUs. | |
707 | ||
debc7065 FB |
708 | @node Index |
709 | @chapter Index | |
710 | @printindex cp | |
711 | ||
712 | @bye |