File:  [Qemu by Fabrice Bellard] / qemu / qemu-tech.texi
Revision 1.1.1.10 (vendor branch): download - view: text, annotated - select for diffs
Tue Apr 24 19:34:53 2018 UTC (3 years, 7 months ago) by root
Branches: qemu, MAIN
CVS tags: qemu1101, HEAD
qemu 1.1.1

    1: \input texinfo @c -*- texinfo -*-
    2: @c %**start of header
    3: @setfilename qemu-tech.info
    4: 
    5: @documentlanguage en
    6: @documentencoding UTF-8
    7: 
    8: @settitle QEMU Internals
    9: @exampleindent 0
   10: @paragraphindent 0
   11: @c %**end of header
   12: 
   13: @ifinfo
   14: @direntry
   15: * QEMU Internals: (qemu-tech).   The QEMU Emulator Internals.
   16: @end direntry
   17: @end ifinfo
   18: 
   19: @iftex
   20: @titlepage
   21: @sp 7
   22: @center @titlefont{QEMU Internals}
   23: @sp 3
   24: @end titlepage
   25: @end iftex
   26: 
   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
   42: @chapter Introduction
   43: 
   44: @menu
   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
   53: @end menu
   54: 
   55: @node intro_features
   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: 
   65: @item
   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.
   71: 
   72: @item
   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.
   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: 
   84: @itemize
   85: 
   86: @item User space only or full system emulation.
   87: 
   88: @item Using dynamic translation to native code for reasonable speed.
   89: 
   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.
   94: 
   95: @item Self-modifying code support.
   96: 
   97: @item Precise exceptions support.
   98: 
   99: @item
  100: Floating point library supporting both full software emulation and
  101: native host FPU instructions.
  102: 
  103: @end itemize
  104: 
  105: QEMU user mode emulation features:
  106: @itemize
  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: 
  111: @item Accurate signal handling by remapping host signals to target signals.
  112: @end itemize
  113: 
  114: Linux user emulator (Linux host only) can be used to launch the Wine
  115: Windows API emulator (@url{http://www.winehq.org}). A BSD user emulator for BSD
  116: hosts is under development. It would also be possible to develop a
  117: similar user emulator for Solaris.
  118: 
  119: QEMU full system emulation features:
  120: @itemize
  121: @item
  122: QEMU uses a full software MMU for maximum portability.
  123: 
  124: @item
  125: QEMU can optionally use an in-kernel accelerator, like kvm. The accelerators 
  126: execute some of the guest code natively, while
  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: 
  141: @end itemize
  142: 
  143: @node intro_x86_emulation
  144: @section x86 and x86-64 emulation
  145: 
  146: QEMU x86 target features:
  147: 
  148: @itemize
  149: 
  150: @item The virtual x86 CPU supports 16 bit and 32 bit addressing with segmentation.
  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.
  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: 
  159: @item An extensive Linux x86 CPU test program is included @file{tests/test-i386}.
  160: It can be used to test other x86 virtual CPUs.
  161: 
  162: @end itemize
  163: 
  164: Current QEMU limitations:
  165: 
  166: @itemize
  167: 
  168: @item Limited x86-64 support.
  169: 
  170: @item IPC syscalls are missing.
  171: 
  172: @item The x86 segment limits and access rights are not tested at every
  173: memory access (yet). Hopefully, very few OSes seem to rely on that for
  174: normal use.
  175: 
  176: @end itemize
  177: 
  178: @node intro_arm_emulation
  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: 
  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: 
  214: @item The watchpoint debug facility is not implemented.
  215: 
  216: @end itemize
  217: 
  218: @node intro_ppc_emulation
  219: @section PowerPC emulation
  220: 
  221: @itemize
  222: 
  223: @item Full PowerPC 32 bit emulation, including privileged instructions,
  224: FPU and MMU.
  225: 
  226: @item Can run most PowerPC Linux binaries.
  227: 
  228: @end itemize
  229: 
  230: @node intro_sparc_emulation
  231: @section Sparc32 and Sparc64 emulation
  232: 
  233: @itemize
  234: 
  235: @item Full SPARC V8 emulation, including privileged
  236: instructions, FPU and MMU. SPARC V9 emulation includes most privileged
  237: and VIS instructions, FPU and I/D MMU. Alignment is fully enforced.
  238: 
  239: @item Can run most 32-bit SPARC Linux binaries, SPARC32PLUS Linux binaries and
  240: some 64-bit SPARC Linux binaries.
  241: 
  242: @end itemize
  243: 
  244: Current QEMU limitations:
  245: 
  246: @itemize
  247: 
  248: @item IPC syscalls are missing.
  249: 
  250: @item Floating point exception support is buggy.
  251: 
  252: @item Atomic instructions are not correctly implemented.
  253: 
  254: @item There are still some problems with Sparc64 emulators.
  255: 
  256: @end itemize
  257: 
  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,
  265: MAC16, miscellaneous operations, boolean, multiprocessor synchronization,
  266: conditional store, exceptions, relocatable vectors, unaligned exception,
  267: interrupts (including high priority and timer), hardware alignment,
  268: region protection, region translation, MMU, windowed registers, thread
  269: pointer, processor ID.
  270: 
  271: @item Not implemented options: FP coprocessor, coprocessor context,
  272: data/instruction cache (including cache prefetch and locking), XLMI,
  273: processor interface, debug. Also options not covered by the core ISA
  274: (e.g. FLIX, wide branches) are not implemented.
  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: 
  283: @node intro_other_emulation
  284: @section Other CPU emulation
  285: 
  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
  299: @end itemize
  300: 
  301: @node QEMU Internals
  302: @chapter QEMU Internals
  303: 
  304: @menu
  305: * QEMU compared to other emulators::
  306: * Portable dynamic translation::
  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::
  314: * Device emulation::
  315: * Hardware interrupts::
  316: * User emulation specific details::
  317: * Bibliography::
  318: @end menu
  319: 
  320: @node QEMU compared to other emulators
  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
  343: executables. Such an approach has greater potential because most of the
  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: 
  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.
  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: 
  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: 
  371: @node Portable dynamic translation
  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: 
  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}.
  390: 
  391: @node Condition code optimisations
  392: @section Condition code optimisations
  393: 
  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
  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.
  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.
  408: 
  409: @code{CC_OP} is almost never explicitly set in the generated code
  410: because it is known at translation time.
  411: 
  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.
  414: 
  415: @node CPU state optimisations
  416: @section CPU state optimisations
  417: 
  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.
  427: 
  428: [The FPU stack pointer register is not handled that way yet].
  429: 
  430: @node Translation cache
  431: @section Translation cache
  432: 
  433: A 32 MByte cache holds the most recently used translations. For
  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: 
  439: @node Direct block chaining
  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: 
  455: @node Self-modifying code and translated code invalidation
  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
  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.
  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
  470: linked lists are also maintained to undo direct block chaining.
  471: 
  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.
  477: 
  478: @node Exception support
  479: @section Exception support
  480: 
  481: longjmp() is used when an exception such as division by zero is
  482: encountered.
  483: 
  484: The host SIGSEGV and SIGBUS signal handlers are used to get invalid
  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.
  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: 
  494: @node MMU emulation
  495: @section MMU emulation
  496: 
  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.
  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
  504: means that each basic block is indexed with its physical address.
  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: 
  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: 
  536: @node Hardware interrupts
  537: @section Hardware interrupts
  538: 
  539: In order to be faster, QEMU does not check at every basic block if an
  540: hardware interrupt is pending. Instead, the user must asynchronously
  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: 
  547: @node User emulation specific details
  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
  572: signals are synthesized from the virtual CPU exceptions such as SIGFPE
  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
  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.
  604: 
  605: @node Bibliography
  606: @section Bibliography
  607: 
  608: @table @asis
  609: 
  610: @item [1]
  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]
  628: @url{http://www.usenix.org/publications/library/proceedings/usenix-nt97/@/full_papers/chernoff/chernoff.pdf},
  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]
  637: @url{http://user-mode-linux.sourceforge.net/},
  638: The User-mode Linux Kernel.
  639: 
  640: @item [8]
  641: @url{http://www.plex86.org/},
  642: The new Plex86 project.
  643: 
  644: @item [9]
  645: @url{http://www.vmware.com/},
  646: The VMWare PC virtualizer.
  647: 
  648: @item [10]
  649: @url{http://www.microsoft.com/windowsxp/virtualpc/},
  650: The VirtualPC PC virtualizer.
  651: 
  652: @item [11]
  653: @url{http://www.twoostwo.org/},
  654: The TwoOStwo PC virtualizer.
  655: 
  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: 
  672: @end table
  673: 
  674: @node Regression Tests
  675: @chapter Regression Tests
  676: 
  677: In the directory @file{tests/}, various interesting testing programs
  678: are available. They are used for regression testing.
  679: 
  680: @menu
  681: * test-i386::
  682: * linux-test::
  683: @end menu
  684: 
  685: @node test-i386
  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: 
  701: @node linux-test
  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: 
  708: @node Index
  709: @chapter Index
  710: @printindex cp
  711: 
  712: @bye

unix.superglobalmegacorp.com