Annotation of qemu/qemu-tech.texi, revision

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