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