blob: 5159fbb114d1bbdaf714f879be7bf80d6dcd5e48 [file] [log] [blame]
bellard1f673132004-04-04 15:21:17 +00001\input texinfo @c -*- texinfo -*-
bellarddebc7062006-04-30 21:58:41 +00002@c %**start of header
3@setfilename qemu-tech.info
4@settitle QEMU Internals
5@exampleindent 0
6@paragraphindent 0
7@c %**end of header
bellard1f673132004-04-04 15:21:17 +00008
9@iftex
bellard1f673132004-04-04 15:21:17 +000010@titlepage
11@sp 7
12@center @titlefont{QEMU Internals}
13@sp 3
14@end titlepage
15@end iftex
16
bellarddebc7062006-04-30 21:58:41 +000017@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
bellard1f673132004-04-04 15:21:17 +000032@chapter Introduction
33
bellarddebc7062006-04-30 21:58:41 +000034@menu
35* intro_features:: Features
36* intro_x86_emulation:: x86 emulation
37* intro_arm_emulation:: ARM emulation
ths24d4de42007-07-11 10:24:28 +000038* intro_mips_emulation:: MIPS emulation
bellarddebc7062006-04-30 21:58:41 +000039* intro_ppc_emulation:: PowerPC emulation
40* intro_sparc_emulation:: SPARC emulation
41@end menu
42
43@node intro_features
bellard1f673132004-04-04 15:21:17 +000044@section Features
45
46QEMU is a FAST! processor emulator using a portable dynamic
47translator.
48
49QEMU has two operating modes:
50
51@itemize @minus
52
ths5fafdf22007-09-16 21:08:06 +000053@item
bellard1f673132004-04-04 15:21:17 +000054Full system emulation. In this mode, QEMU emulates a full system
bellardb671f9e2005-04-30 15:08:33 +000055(usually a PC), including a processor and various peripherals. It can
bellard1f673132004-04-04 15:21:17 +000056be used to launch an different Operating System without rebooting the
57PC or to debug system code.
58
ths5fafdf22007-09-16 21:08:06 +000059@item
bellard1f673132004-04-04 15:21:17 +000060User mode emulation (Linux host only). In this mode, QEMU can launch
61Linux processes compiled for one CPU on another CPU. It can be used to
62launch the Wine Windows API emulator (@url{http://www.winehq.org}) or
63to ease cross-compilation and cross-debugging.
64
65@end itemize
66
67As QEMU requires no host kernel driver to run, it is very safe and
68easy to use.
69
70QEMU generic features:
71
ths5fafdf22007-09-16 21:08:06 +000072@itemize
bellard1f673132004-04-04 15:21:17 +000073
74@item User space only or full system emulation.
75
bellarddebc7062006-04-30 21:58:41 +000076@item Using dynamic translation to native code for reasonable speed.
bellard1f673132004-04-04 15:21:17 +000077
78@item Working on x86 and PowerPC hosts. Being tested on ARM, Sparc32, Alpha and S390.
79
80@item Self-modifying code support.
81
82@item Precise exceptions support.
83
ths5fafdf22007-09-16 21:08:06 +000084@item The virtual CPU is a library (@code{libqemu}) which can be used
bellardad6a4832004-04-24 00:16:28 +000085in other projects (look at @file{qemu/tests/qruncom.c} to have an
86example of user mode @code{libqemu} usage).
bellard1f673132004-04-04 15:21:17 +000087
88@end itemize
89
90QEMU user mode emulation features:
ths5fafdf22007-09-16 21:08:06 +000091@itemize
bellard1f673132004-04-04 15:21:17 +000092@item Generic Linux system call converter, including most ioctls.
93
94@item clone() emulation using native CPU clone() to use Linux scheduler for threads.
95
ths5fafdf22007-09-16 21:08:06 +000096@item Accurate signal handling by remapping host signals to target signals.
bellard1f673132004-04-04 15:21:17 +000097@end itemize
bellard1f673132004-04-04 15:21:17 +000098
99QEMU full system emulation features:
ths5fafdf22007-09-16 21:08:06 +0000100@itemize
bellard1f673132004-04-04 15:21:17 +0000101@item QEMU can either use a full software MMU for maximum portability or use the host system call mmap() to simulate the target MMU.
102@end itemize
103
bellarddebc7062006-04-30 21:58:41 +0000104@node intro_x86_emulation
bellard1f673132004-04-04 15:21:17 +0000105@section x86 emulation
106
107QEMU x86 target features:
108
ths5fafdf22007-09-16 21:08:06 +0000109@itemize
bellard1f673132004-04-04 15:21:17 +0000110
ths5fafdf22007-09-16 21:08:06 +0000111@item The virtual x86 CPU supports 16 bit and 32 bit addressing with segmentation.
bellard1f673132004-04-04 15:21:17 +0000112LDT/GDT and IDT are emulated. VM86 mode is also supported to run DOSEMU.
113
114@item Support of host page sizes bigger than 4KB in user mode emulation.
115
116@item QEMU can emulate itself on x86.
117
ths5fafdf22007-09-16 21:08:06 +0000118@item An extensive Linux x86 CPU test program is included @file{tests/test-i386}.
bellard1f673132004-04-04 15:21:17 +0000119It can be used to test other x86 virtual CPUs.
120
121@end itemize
122
123Current QEMU limitations:
124
ths5fafdf22007-09-16 21:08:06 +0000125@itemize
bellard1f673132004-04-04 15:21:17 +0000126
127@item No SSE/MMX support (yet).
128
129@item No x86-64 support.
130
131@item IPC syscalls are missing.
132
ths5fafdf22007-09-16 21:08:06 +0000133@item The x86 segment limits and access rights are not tested at every
bellard1f673132004-04-04 15:21:17 +0000134memory access (yet). Hopefully, very few OSes seem to rely on that for
135normal use.
136
ths5fafdf22007-09-16 21:08:06 +0000137@item On non x86 host CPUs, @code{double}s are used instead of the non standard
bellard1f673132004-04-04 15:21:17 +000013810 byte @code{long double}s of x86 for floating point emulation to get
139maximum performances.
140
141@end itemize
142
bellarddebc7062006-04-30 21:58:41 +0000143@node intro_arm_emulation
bellard1f673132004-04-04 15:21:17 +0000144@section ARM emulation
145
146@itemize
147
148@item Full ARM 7 user emulation.
149
150@item NWFPE FPU support included in user Linux emulation.
151
152@item Can run most ARM Linux binaries.
153
154@end itemize
155
ths24d4de42007-07-11 10:24:28 +0000156@node intro_mips_emulation
157@section MIPS emulation
158
159@itemize
160
161@item The system emulation allows full MIPS32/MIPS64 Release 2 emulation,
162including privileged instructions, FPU and MMU, in both little and big
163endian modes.
164
165@item The Linux userland emulation can run many 32 bit MIPS Linux binaries.
166
167@end itemize
168
169Current QEMU limitations:
170
171@itemize
172
173@item Self-modifying code is not always handled correctly.
174
175@item 64 bit userland emulation is not implemented.
176
177@item The system emulation is not complete enough to run real firmware.
178
thsb1f45232007-07-12 09:03:30 +0000179@item The watchpoint debug facility is not implemented.
180
ths24d4de42007-07-11 10:24:28 +0000181@end itemize
182
bellarddebc7062006-04-30 21:58:41 +0000183@node intro_ppc_emulation
bellard1f673132004-04-04 15:21:17 +0000184@section PowerPC emulation
185
186@itemize
187
ths5fafdf22007-09-16 21:08:06 +0000188@item Full PowerPC 32 bit emulation, including privileged instructions,
bellard1f673132004-04-04 15:21:17 +0000189FPU and MMU.
190
191@item Can run most PowerPC Linux binaries.
192
193@end itemize
194
bellarddebc7062006-04-30 21:58:41 +0000195@node intro_sparc_emulation
bellard1f673132004-04-04 15:21:17 +0000196@section SPARC emulation
197
198@itemize
199
blueswir1f6b647c2007-04-05 18:40:23 +0000200@item Full SPARC V8 emulation, including privileged
bellard34751872005-07-02 14:31:34 +0000201instructions, FPU and MMU. SPARC V9 emulation includes most privileged
blueswir1a785e422007-10-20 08:09:05 +0000202and VIS instructions, FPU and I/D MMU. Alignment is fully enforced.
bellard1f673132004-04-04 15:21:17 +0000203
blueswir1a785e422007-10-20 08:09:05 +0000204@item Can run most 32-bit SPARC Linux binaries, SPARC32PLUS Linux binaries and
205some 64-bit SPARC Linux binaries.
bellard34751872005-07-02 14:31:34 +0000206
207@end itemize
208
209Current QEMU limitations:
210
ths5fafdf22007-09-16 21:08:06 +0000211@itemize
bellard34751872005-07-02 14:31:34 +0000212
bellard34751872005-07-02 14:31:34 +0000213@item IPC syscalls are missing.
214
blueswir11f587322007-11-25 18:40:20 +0000215@item Floating point exception support is buggy.
bellard34751872005-07-02 14:31:34 +0000216
217@item Atomic instructions are not correctly implemented.
218
219@item Sparc64 emulators are not usable for anything yet.
bellard1f673132004-04-04 15:21:17 +0000220
221@end itemize
222
bellarddebc7062006-04-30 21:58:41 +0000223@node QEMU Internals
bellard1f673132004-04-04 15:21:17 +0000224@chapter QEMU Internals
225
bellarddebc7062006-04-30 21:58:41 +0000226@menu
227* QEMU compared to other emulators::
228* Portable dynamic translation::
229* Register allocation::
230* Condition code optimisations::
231* CPU state optimisations::
232* Translation cache::
233* Direct block chaining::
234* Self-modifying code and translated code invalidation::
235* Exception support::
236* MMU emulation::
237* Hardware interrupts::
238* User emulation specific details::
239* Bibliography::
240@end menu
241
242@node QEMU compared to other emulators
bellard1f673132004-04-04 15:21:17 +0000243@section QEMU compared to other emulators
244
245Like bochs [3], QEMU emulates an x86 CPU. But QEMU is much faster than
246bochs as it uses dynamic compilation. Bochs is closely tied to x86 PC
247emulation while QEMU can emulate several processors.
248
249Like Valgrind [2], QEMU does user space emulation and dynamic
250translation. Valgrind is mainly a memory debugger while QEMU has no
251support for it (QEMU could be used to detect out of bound memory
252accesses as Valgrind, but it has no support to track uninitialised data
253as Valgrind does). The Valgrind dynamic translator generates better code
254than QEMU (in particular it does register allocation) but it is closely
255tied to an x86 host and target and has no support for precise exceptions
256and system emulation.
257
258EM86 [4] is the closest project to user space QEMU (and QEMU still uses
259some of its code, in particular the ELF file loader). EM86 was limited
260to an alpha host and used a proprietary and slow interpreter (the
261interpreter part of the FX!32 Digital Win32 code translator [5]).
262
263TWIN [6] is a Windows API emulator like Wine. It is less accurate than
264Wine but includes a protected mode x86 interpreter to launch x86 Windows
bellard36d54d12004-09-05 16:04:16 +0000265executables. Such an approach has greater potential because most of the
bellard1f673132004-04-04 15:21:17 +0000266Windows API is executed natively but it is far more difficult to develop
267because all the data structures and function parameters exchanged
268between the API and the x86 code must be converted.
269
270User mode Linux [7] was the only solution before QEMU to launch a
271Linux kernel as a process while not needing any host kernel
272patches. However, user mode Linux requires heavy kernel patches while
273QEMU accepts unpatched Linux kernels. The price to pay is that QEMU is
274slower.
275
276The new Plex86 [8] PC virtualizer is done in the same spirit as the
277qemu-fast system emulator. It requires a patched Linux kernel to work
278(you cannot launch the same kernel on your PC), but the patches are
279really small. As it is a PC virtualizer (no emulation is done except
ths1235fc02008-06-03 19:51:57 +0000280for some privileged instructions), it has the potential of being
bellard1f673132004-04-04 15:21:17 +0000281faster than QEMU. The downside is that a complicated (and potentially
282unsafe) host kernel patch is needed.
283
284The commercial PC Virtualizers (VMWare [9], VirtualPC [10], TwoOStwo
285[11]) are faster than QEMU, but they all need specific, proprietary
286and potentially unsafe host drivers. Moreover, they are unable to
287provide cycle exact simulation as an emulator can.
288
bellarddebc7062006-04-30 21:58:41 +0000289@node Portable dynamic translation
bellard1f673132004-04-04 15:21:17 +0000290@section Portable dynamic translation
291
292QEMU is a dynamic translator. When it first encounters a piece of code,
293it converts it to the host instruction set. Usually dynamic translators
294are very complicated and highly CPU dependent. QEMU uses some tricks
295which make it relatively easily portable and simple while achieving good
296performances.
297
298The basic idea is to split every x86 instruction into fewer simpler
299instructions. Each simple instruction is implemented by a piece of C
300code (see @file{target-i386/op.c}). Then a compile time tool
301(@file{dyngen}) takes the corresponding object file (@file{op.o})
302to generate a dynamic code generator which concatenates the simple
303instructions to build a function (see @file{op.h:dyngen_code()}).
304
305In essence, the process is similar to [1], but more work is done at
ths5fafdf22007-09-16 21:08:06 +0000306compile time.
bellard1f673132004-04-04 15:21:17 +0000307
308A key idea to get optimal performances is that constant parameters can
309be passed to the simple operations. For that purpose, dummy ELF
310relocations are generated with gcc for each constant parameter. Then,
311the tool (@file{dyngen}) can locate the relocations and generate the
312appriopriate C code to resolve them when building the dynamic code.
313
314That way, QEMU is no more difficult to port than a dynamic linker.
315
316To go even faster, GCC static register variables are used to keep the
317state of the virtual CPU.
318
bellarddebc7062006-04-30 21:58:41 +0000319@node Register allocation
bellard1f673132004-04-04 15:21:17 +0000320@section Register allocation
321
322Since QEMU uses fixed simple instructions, no efficient register
323allocation can be done. However, because RISC CPUs have a lot of
324register, most of the virtual CPU state can be put in registers without
325doing complicated register allocation.
326
bellarddebc7062006-04-30 21:58:41 +0000327@node Condition code optimisations
bellard1f673132004-04-04 15:21:17 +0000328@section Condition code optimisations
329
330Good CPU condition codes emulation (@code{EFLAGS} register on x86) is a
331critical point to get good performances. QEMU uses lazy condition code
332evaluation: instead of computing the condition codes after each x86
333instruction, it just stores one operand (called @code{CC_SRC}), the
334result (called @code{CC_DST}) and the type of operation (called
335@code{CC_OP}).
336
ths1235fc02008-06-03 19:51:57 +0000337@code{CC_OP} is almost never explicitly set in the generated code
bellard1f673132004-04-04 15:21:17 +0000338because it is known at translation time.
339
340In order to increase performances, a backward pass is performed on the
341generated simple instructions (see
342@code{target-i386/translate.c:optimize_flags()}). When it can be proved that
343the condition codes are not needed by the next instructions, no
344condition codes are computed at all.
345
bellarddebc7062006-04-30 21:58:41 +0000346@node CPU state optimisations
bellard1f673132004-04-04 15:21:17 +0000347@section CPU state optimisations
348
349The x86 CPU has many internal states which change the way it evaluates
350instructions. In order to achieve a good speed, the translation phase
351considers that some state information of the virtual x86 CPU cannot
352change in it. For example, if the SS, DS and ES segments have a zero
353base, then the translator does not even generate an addition for the
354segment base.
355
356[The FPU stack pointer register is not handled that way yet].
357
bellarddebc7062006-04-30 21:58:41 +0000358@node Translation cache
bellard1f673132004-04-04 15:21:17 +0000359@section Translation cache
360
bellard15a34c62004-07-08 21:26:26 +0000361A 16 MByte cache holds the most recently used translations. For
bellard1f673132004-04-04 15:21:17 +0000362simplicity, it is completely flushed when it is full. A translation unit
363contains just a single basic block (a block of x86 instructions
364terminated by a jump or by a virtual CPU state change which the
365translator cannot deduce statically).
366
bellarddebc7062006-04-30 21:58:41 +0000367@node Direct block chaining
bellard1f673132004-04-04 15:21:17 +0000368@section Direct block chaining
369
370After each translated basic block is executed, QEMU uses the simulated
371Program Counter (PC) and other cpu state informations (such as the CS
372segment base value) to find the next basic block.
373
374In order to accelerate the most common cases where the new simulated PC
375is known, QEMU can patch a basic block so that it jumps directly to the
376next one.
377
378The most portable code uses an indirect jump. An indirect jump makes
379it easier to make the jump target modification atomic. On some host
380architectures (such as x86 or PowerPC), the @code{JUMP} opcode is
381directly patched so that the block chaining has no overhead.
382
bellarddebc7062006-04-30 21:58:41 +0000383@node Self-modifying code and translated code invalidation
bellard1f673132004-04-04 15:21:17 +0000384@section Self-modifying code and translated code invalidation
385
386Self-modifying code is a special challenge in x86 emulation because no
387instruction cache invalidation is signaled by the application when code
388is modified.
389
390When translated code is generated for a basic block, the corresponding
391host page is write protected if it is not already read-only (with the
392system call @code{mprotect()}). Then, if a write access is done to the
393page, Linux raises a SEGV signal. QEMU then invalidates all the
394translated code in the page and enables write accesses to the page.
395
396Correct translated code invalidation is done efficiently by maintaining
397a linked list of every translated block contained in a given page. Other
ths5fafdf22007-09-16 21:08:06 +0000398linked lists are also maintained to undo direct block chaining.
bellard1f673132004-04-04 15:21:17 +0000399
400Although the overhead of doing @code{mprotect()} calls is important,
401most MSDOS programs can be emulated at reasonnable speed with QEMU and
402DOSEMU.
403
404Note that QEMU also invalidates pages of translated code when it detects
405that memory mappings are modified with @code{mmap()} or @code{munmap()}.
406
407When using a software MMU, the code invalidation is more efficient: if
408a given code page is invalidated too often because of write accesses,
409then a bitmap representing all the code inside the page is
410built. Every store into that page checks the bitmap to see if the code
411really needs to be invalidated. It avoids invalidating the code when
412only data is modified in the page.
413
bellarddebc7062006-04-30 21:58:41 +0000414@node Exception support
bellard1f673132004-04-04 15:21:17 +0000415@section Exception support
416
417longjmp() is used when an exception such as division by zero is
ths5fafdf22007-09-16 21:08:06 +0000418encountered.
bellard1f673132004-04-04 15:21:17 +0000419
420The host SIGSEGV and SIGBUS signal handlers are used to get invalid
421memory accesses. The exact CPU state can be retrieved because all the
422x86 registers are stored in fixed host registers. The simulated program
423counter is found by retranslating the corresponding basic block and by
424looking where the host program counter was at the exception point.
425
426The virtual CPU cannot retrieve the exact @code{EFLAGS} register because
427in some cases it is not computed because of condition code
428optimisations. It is not a big concern because the emulated code can
429still be restarted in any cases.
430
bellarddebc7062006-04-30 21:58:41 +0000431@node MMU emulation
bellard1f673132004-04-04 15:21:17 +0000432@section MMU emulation
433
434For system emulation, QEMU uses the mmap() system call to emulate the
435target CPU MMU. It works as long the emulated OS does not use an area
436reserved by the host OS (such as the area above 0xc0000000 on x86
437Linux).
438
439In order to be able to launch any OS, QEMU also supports a soft
440MMU. In that mode, the MMU virtual to physical address translation is
441done at every memory access. QEMU uses an address translation cache to
442speed up the translation.
443
444In order to avoid flushing the translated code each time the MMU
445mappings change, QEMU uses a physically indexed translation cache. It
ths5fafdf22007-09-16 21:08:06 +0000446means that each basic block is indexed with its physical address.
bellard1f673132004-04-04 15:21:17 +0000447
448When MMU mappings change, only the chaining of the basic blocks is
449reset (i.e. a basic block can no longer jump directly to another one).
450
bellarddebc7062006-04-30 21:58:41 +0000451@node Hardware interrupts
bellard1f673132004-04-04 15:21:17 +0000452@section Hardware interrupts
453
454In order to be faster, QEMU does not check at every basic block if an
455hardware interrupt is pending. Instead, the user must asynchrously
456call a specific function to tell that an interrupt is pending. This
457function resets the chaining of the currently executing basic
458block. It ensures that the execution will return soon in the main loop
459of the CPU emulator. Then the main loop can test if the interrupt is
460pending and handle it.
461
bellarddebc7062006-04-30 21:58:41 +0000462@node User emulation specific details
bellard1f673132004-04-04 15:21:17 +0000463@section User emulation specific details
464
465@subsection Linux system call translation
466
467QEMU includes a generic system call translator for Linux. It means that
468the parameters of the system calls can be converted to fix the
469endianness and 32/64 bit issues. The IOCTLs are converted with a generic
470type description system (see @file{ioctls.h} and @file{thunk.c}).
471
472QEMU supports host CPUs which have pages bigger than 4KB. It records all
473the mappings the process does and try to emulated the @code{mmap()}
474system calls in cases where the host @code{mmap()} call would fail
475because of bad page alignment.
476
477@subsection Linux signals
478
479Normal and real-time signals are queued along with their information
480(@code{siginfo_t}) as it is done in the Linux kernel. Then an interrupt
481request is done to the virtual CPU. When it is interrupted, one queued
482signal is handled by generating a stack frame in the virtual CPU as the
483Linux kernel does. The @code{sigreturn()} system call is emulated to return
484from the virtual signal handler.
485
486Some signals (such as SIGALRM) directly come from the host. Other
487signals are synthetized from the virtual CPU exceptions such as SIGFPE
488when a division by zero is done (see @code{main.c:cpu_loop()}).
489
490The blocked signal mask is still handled by the host Linux kernel so
491that most signal system calls can be redirected directly to the host
492Linux kernel. Only the @code{sigaction()} and @code{sigreturn()} system
493calls need to be fully emulated (see @file{signal.c}).
494
495@subsection clone() system call and threads
496
497The Linux clone() system call is usually used to create a thread. QEMU
498uses the host clone() system call so that real host threads are created
499for each emulated thread. One virtual CPU instance is created for each
500thread.
501
502The virtual x86 CPU atomic operations are emulated with a global lock so
503that their semantic is preserved.
504
505Note that currently there are still some locking issues in QEMU. In
506particular, the translated cache flush is not protected yet against
507reentrancy.
508
509@subsection Self-virtualization
510
511QEMU was conceived so that ultimately it can emulate itself. Although
512it is not very useful, it is an important test to show the power of the
513emulator.
514
515Achieving self-virtualization is not easy because there may be address
516space conflicts. QEMU solves this problem by being an executable ELF
517shared object as the ld-linux.so ELF interpreter. That way, it can be
518relocated at load time.
519
bellarddebc7062006-04-30 21:58:41 +0000520@node Bibliography
bellard1f673132004-04-04 15:21:17 +0000521@section Bibliography
522
523@table @asis
524
ths5fafdf22007-09-16 21:08:06 +0000525@item [1]
bellard1f673132004-04-04 15:21:17 +0000526@url{http://citeseer.nj.nec.com/piumarta98optimizing.html}, Optimizing
527direct threaded code by selective inlining (1998) by Ian Piumarta, Fabio
528Riccardi.
529
530@item [2]
531@url{http://developer.kde.org/~sewardj/}, Valgrind, an open-source
532memory debugger for x86-GNU/Linux, by Julian Seward.
533
534@item [3]
535@url{http://bochs.sourceforge.net/}, the Bochs IA-32 Emulator Project,
536by Kevin Lawton et al.
537
538@item [4]
539@url{http://www.cs.rose-hulman.edu/~donaldlf/em86/index.html}, the EM86
540x86 emulator on Alpha-Linux.
541
542@item [5]
bellarddebc7062006-04-30 21:58:41 +0000543@url{http://www.usenix.org/publications/library/proceedings/usenix-nt97/@/full_papers/chernoff/chernoff.pdf},
bellard1f673132004-04-04 15:21:17 +0000544DIGITAL FX!32: Running 32-Bit x86 Applications on Alpha NT, by Anton
545Chernoff and Ray Hookway.
546
547@item [6]
548@url{http://www.willows.com/}, Windows API library emulation from
549Willows Software.
550
551@item [7]
ths5fafdf22007-09-16 21:08:06 +0000552@url{http://user-mode-linux.sourceforge.net/},
bellard1f673132004-04-04 15:21:17 +0000553The User-mode Linux Kernel.
554
555@item [8]
ths5fafdf22007-09-16 21:08:06 +0000556@url{http://www.plex86.org/},
bellard1f673132004-04-04 15:21:17 +0000557The new Plex86 project.
558
559@item [9]
ths5fafdf22007-09-16 21:08:06 +0000560@url{http://www.vmware.com/},
bellard1f673132004-04-04 15:21:17 +0000561The VMWare PC virtualizer.
562
563@item [10]
ths5fafdf22007-09-16 21:08:06 +0000564@url{http://www.microsoft.com/windowsxp/virtualpc/},
bellard1f673132004-04-04 15:21:17 +0000565The VirtualPC PC virtualizer.
566
567@item [11]
ths5fafdf22007-09-16 21:08:06 +0000568@url{http://www.twoostwo.org/},
bellard1f673132004-04-04 15:21:17 +0000569The TwoOStwo PC virtualizer.
570
571@end table
572
bellarddebc7062006-04-30 21:58:41 +0000573@node Regression Tests
bellard1f673132004-04-04 15:21:17 +0000574@chapter Regression Tests
575
576In the directory @file{tests/}, various interesting testing programs
thsb1f45232007-07-12 09:03:30 +0000577are available. They are used for regression testing.
bellard1f673132004-04-04 15:21:17 +0000578
bellarddebc7062006-04-30 21:58:41 +0000579@menu
580* test-i386::
581* linux-test::
582* qruncom.c::
583@end menu
584
585@node test-i386
bellard1f673132004-04-04 15:21:17 +0000586@section @file{test-i386}
587
588This program executes most of the 16 bit and 32 bit x86 instructions and
589generates a text output. It can be compared with the output obtained with
590a real CPU or another emulator. The target @code{make test} runs this
591program and a @code{diff} on the generated output.
592
593The Linux system call @code{modify_ldt()} is used to create x86 selectors
594to test some 16 bit addressing and 32 bit with segmentation cases.
595
596The Linux system call @code{vm86()} is used to test vm86 emulation.
597
598Various exceptions are raised to test most of the x86 user space
599exception reporting.
600
bellarddebc7062006-04-30 21:58:41 +0000601@node linux-test
bellard1f673132004-04-04 15:21:17 +0000602@section @file{linux-test}
603
604This program tests various Linux system calls. It is used to verify
605that the system call parameters are correctly converted between target
606and host CPUs.
607
bellarddebc7062006-04-30 21:58:41 +0000608@node qruncom.c
bellard15a34c62004-07-08 21:26:26 +0000609@section @file{qruncom.c}
bellard1f673132004-04-04 15:21:17 +0000610
bellard15a34c62004-07-08 21:26:26 +0000611Example of usage of @code{libqemu} to emulate a user mode i386 CPU.
bellarddebc7062006-04-30 21:58:41 +0000612
613@node Index
614@chapter Index
615@printindex cp
616
617@bye