\input texinfo @c -*- texinfo -*-
-@settitle QEMU x86 Emulator Reference Documentation
+@settitle QEMU CPU Emulator Reference Documentation
@titlepage
@sp 7
-@center @titlefont{QEMU x86 Emulator Reference Documentation}
+@center @titlefont{QEMU CPU Emulator Reference Documentation}
@sp 3
@end titlepage
@chapter Introduction
-QEMU is an x86 processor emulator. Its purpose is to run x86 Linux
-processes on non-x86 Linux architectures such as PowerPC or ARM. By
-using dynamic translation it achieves a reasonnable speed while being
-easy to port on new host CPUs. An obviously interesting x86 only process
-is 'wine' (Windows emulation).
+@section Features
-QEMU features:
+QEMU is a FAST! processor emulator. By using dynamic translation it
+achieves a reasonnable speed while being easy to port on new host
+CPUs.
-@itemize
+QEMU has two operating modes:
+@itemize
+@item User mode emulation. In this mode, QEMU can launch Linux processes
+compiled for one CPU on another CPU. Linux system calls are converted
+because of endianness and 32/64 bit mismatches. The Wine Windows API
+emulator (@url{http://www.winehq.org}) and the DOSEMU DOS emulator
+(@url{www.dosemu.org}) are the main targets for QEMU.
-@item User space only x86 emulator.
+@item Full system emulation. In this mode, QEMU emulates a full
+system, including a processor and various peripherials. Currently, it
+is only used to launch an x86 Linux kernel on an x86 Linux system. It
+enables easier testing and debugging of system code. It can also be
+used to provide virtual hosting of several virtual PCs on a single
+server.
-@item Currently ported on i386 and PowerPC.
+@end itemize
-@item Using dynamic translation for reasonnable speed.
+As QEMU requires no host kernel patches to run, it is very safe and
+easy to use.
-@item The virtual x86 CPU supports 16 bit and 32 bit addressing with segmentation.
-User space LDT and GDT are emulated.
+QEMU generic features:
-@item Generic Linux system call converter, including most ioctls.
+@itemize
-@item clone() emulation using native CPU clone() to use Linux scheduler for threads.
+@item User space only or full system emulation.
+
+@item Using dynamic translation to native code for reasonnable speed.
+
+@item Working on x86 and PowerPC hosts. Being tested on ARM, Sparc32, Alpha and S390.
+
+@item Self-modifying code support.
-@item Accurate signal handling by remapping host signals to virtual x86 signals.
+@item Precise exceptions support.
-@item The virtual x86 CPU is a library (@code{libqemu}) which can be used
+@item The virtual CPU is a library (@code{libqemu}) which can be used
in other projects.
-@item An extensive Linux x86 CPU test program is included @file{tests/test-i386}.
-It can be used to test other x86 virtual CPUs.
+@end itemize
+
+QEMU user mode emulation features:
+@itemize
+@item Generic Linux system call converter, including most ioctls.
+
+@item clone() emulation using native CPU clone() to use Linux scheduler for threads.
+
+@item Accurate signal handling by remapping host signals to target signals.
+@end itemize
+@end itemize
+QEMU full system emulation features:
+@itemize
+@item Using mmap() system calls to simulate the MMU
@end itemize
-Current QEMU Limitations:
+@section x86 emulation
+
+QEMU x86 target features:
@itemize
-@item Not all x86 exceptions are precise (yet). [Very few programs need that].
+@item The virtual x86 CPU supports 16 bit and 32 bit addressing with segmentation.
+LDT/GDT and IDT are emulated. VM86 mode is also supported to run DOSEMU.
+
+@item Support of host page sizes bigger than 4KB in user mode emulation.
+
+@item QEMU can emulate itself on x86.
+
+@item An extensive Linux x86 CPU test program is included @file{tests/test-i386}.
+It can be used to test other x86 virtual CPUs.
-@item Not self virtualizable (yet). [You cannot launch qemu with qemu on the same CPU].
+@end itemize
-@item No support for self modifying code (yet). [Very few programs need that, a notable exception is QEMU itself !].
+Current QEMU limitations:
-@item No VM86 mode (yet), althought the virtual
-CPU has support for most of it. [VM86 support is useful to launch old 16
-bit DOS programs with dosemu or wine].
+@itemize
@item No SSE/MMX support (yet).
@item No x86-64 support.
-@item Some Linux syscalls are missing.
+@item IPC syscalls are missing.
@item The x86 segment limits and access rights are not tested at every
-memory access (and will never be to have good performances).
+memory access.
@item On non x86 host CPUs, @code{double}s are used instead of the non standard
10 byte @code{long double}s of x86 for floating point emulation to get
maximum performances.
+@item Full system emulation only works if no data are mapped above the virtual address
+0xc0000000 (yet).
+
+@item Some priviledged instructions or behaviors are missing. Only the ones
+needed for proper Linux kernel operation are emulated.
+
+@item No memory separation between the kernel and the user processes is done.
+It will be implemented very soon.
+
@end itemize
-@chapter Invocation
+@section ARM emulation
+
+@itemize
+
+@item ARM emulation can currently launch small programs while using the
+generic dynamic code generation architecture of QEMU.
+
+@item No FPU support (yet).
+
+@item No automatic regression testing (yet).
+
+@end itemize
+
+@chapter QEMU User space emulator invocation
+
+@section Quick Start
+
+If you need to compile QEMU, please read the @file{README} which gives
+the related information.
In order to launch a Linux process, QEMU needs the process executable
-itself and all the target (x86) dynamic libraries used by it. Currently,
-QEMU is not distributed with the necessary packages so that you can test
-it easily on non x86 CPUs.
+itself and all the target (x86) dynamic libraries used by it.
+
+@itemize
-However, the statically x86 binary 'tests/hello' can be used to do a
-first test:
+@item On x86, you can just try to launch any process by using the native
+libraries:
@example
-qemu tests/hello
+qemu -L / /bin/ls
@end example
-@code{Hello world} should be printed on the terminal.
+@code{-L /} tells that the x86 dynamic linker must be searched with a
+@file{/} prefix.
-If you are testing it on a x86 CPU, then you can test it on any process:
+@item Since QEMU is also a linux process, you can launch qemu with qemu:
@example
-qemu /bin/ls -l
+qemu -L / qemu -L / /bin/ls
+@end example
+
+@item On non x86 CPUs, you need first to download at least an x86 glibc
+(@file{qemu-XXX-i386-glibc21.tar.gz} on the QEMU web page). Ensure that
+@code{LD_LIBRARY_PATH} is not set:
+
+@example
+unset LD_LIBRARY_PATH
+@end example
+
+Then you can launch the precompiled @file{ls} x86 executable:
+
+@example
+qemu /usr/local/qemu-i386/bin/ls-i386
+@end example
+You can look at @file{/usr/local/qemu-i386/bin/qemu-conf.sh} so that
+QEMU is automatically launched by the Linux kernel when you try to
+launch x86 executables. It requires the @code{binfmt_misc} module in the
+Linux kernel.
+
+@item The x86 version of QEMU is also included. You can try weird things such as:
+@example
+qemu /usr/local/qemu-i386/bin/qemu-i386 /usr/local/qemu-i386/bin/ls-i386
+@end example
+
+@end itemize
+
+@section Wine launch
+
+@itemize
+
+@item Ensure that you have a working QEMU with the x86 glibc
+distribution (see previous section). In order to verify it, you must be
+able to do:
+
+@example
+qemu /usr/local/qemu-i386/bin/ls-i386
+@end example
+
+@item Download the binary x86 Wine install
+(@file{qemu-XXX-i386-wine.tar.gz} on the QEMU web page).
+
+@item Configure Wine on your account. Look at the provided script
+@file{/usr/local/qemu-i386/bin/wine-conf.sh}. Your previous
+@code{$@{HOME@}/.wine} directory is saved to @code{$@{HOME@}/.wine.org}.
+
+@item Then you can try the example @file{putty.exe}:
+
+@example
+qemu /usr/local/qemu-i386/wine/bin/wine /usr/local/qemu-i386/wine/c/Program\ Files/putty.exe
+@end example
+
+@end itemize
+
+@section Command line options
+
+@example
+usage: qemu [-h] [-d] [-L path] [-s size] program [arguments...]
+@end example
+
+@table @option
+@item -h
+Print the help
+@item -L path
+Set the x86 elf interpreter prefix (default=/usr/local/qemu-i386)
+@item -s size
+Set the x86 stack size in bytes (default=524288)
+@end table
+
+Debug options:
+
+@table @option
+@item -d
+Activate log (logfile=/tmp/qemu.log)
+@item -p pagesize
+Act as if the host page size was 'pagesize' bytes
+@end table
+
+@chapter QEMU System emulator invocation
+
+@section Quick Start
+
+This section explains how to launch a Linux kernel inside QEMU.
+
+@enumerate
+@item
+Download the archive @file{vl-test-xxx.tar.gz} containing a Linux kernel
+and an initrd (initial Ram Disk). The archive also contains a
+precompiled version of @file{vl}, the QEMU System emulator.
+
+@item Optional: If you want network support (for example to launch X11 examples), you
+must copy the script @file{vl-ifup} in @file{/etc} and configure
+properly @code{sudo} so that the command @code{ifconfig} contained in
+@file{vl-ifup} can be executed as root. You must verify that your host
+kernel supports the TUN/TAP network interfaces: the device
+@file{/dev/net/tun} must be present.
+
+When network is enabled, there is a virtual network connection between
+the host kernel and the emulated kernel. The emulated kernel is seen
+from the host kernel at IP address 172.20.0.2 and the host kernel is
+seen from the emulated kernel at IP address 172.20.0.1.
+
+@item Launch @code{vl.sh}. You should have the following output:
+
+@example
+> ./vl.sh
+connected to host network interface: tun0
+Uncompressing Linux... Ok, booting the kernel.
+Linux version 2.4.20 (bellard@voyager) (gcc version 2.95.2 20000220 (Debian GNU/Linux)) #42 Wed Jun 25 14:16:12 CEST 2003
+BIOS-provided physical RAM map:
+ BIOS-88: 0000000000000000 - 000000000009f000 (usable)
+ BIOS-88: 0000000000100000 - 0000000002000000 (usable)
+32MB LOWMEM available.
+On node 0 totalpages: 8192
+zone(0): 4096 pages.
+zone(1): 4096 pages.
+zone(2): 0 pages.
+Kernel command line: root=/dev/ram ramdisk_size=6144
+Initializing CPU#0
+Detected 501.785 MHz processor.
+Calibrating delay loop... 973.20 BogoMIPS
+Memory: 24776k/32768k available (725k kernel code, 7604k reserved, 151k data, 48k init, 0k highmem)
+Dentry cache hash table entries: 4096 (order: 3, 32768 bytes)
+Inode cache hash table entries: 2048 (order: 2, 16384 bytes)
+Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
+Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes)
+Page-cache hash table entries: 8192 (order: 3, 32768 bytes)
+CPU: Intel Pentium Pro stepping 03
+Checking 'hlt' instruction... OK.
+POSIX conformance testing by UNIFIX
+Linux NET4.0 for Linux 2.4
+Based upon Swansea University Computer Society NET3.039
+Initializing RT netlink socket
+apm: BIOS not found.
+Starting kswapd
+pty: 256 Unix98 ptys configured
+Serial driver version 5.05c (2001-07-08) with no serial options enabled
+ttyS00 at 0x03f8 (irq = 4) is a 16450
+ne.c:v1.10 9/23/94 Donald Becker (becker@scyld.com)
+Last modified Nov 1, 2000 by Paul Gortmaker
+NE*000 ethercard probe at 0x300: 52 54 00 12 34 56
+eth0: NE2000 found at 0x300, using IRQ 9.
+RAMDISK driver initialized: 16 RAM disks of 6144K size 1024 blocksize
+NET4: Linux TCP/IP 1.0 for NET4.0
+IP Protocols: ICMP, UDP, TCP, IGMP
+IP: routing cache hash table of 512 buckets, 4Kbytes
+TCP: Hash tables configured (established 2048 bind 2048)
+NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
+RAMDISK: ext2 filesystem found at block 0
+RAMDISK: Loading 6144 blocks [1 disk] into ram disk... done.
+Freeing initrd memory: 6144k freed
+VFS: Mounted root (ext2 filesystem).
+Freeing unused kernel memory: 48k freed
+sh: can't access tty; job control turned off
+#
+@end example
+
+@item
+Then you can play with the kernel inside the virtual serial console. You
+can launch @code{ls} for example. Type @key{Ctrl-a h} to have an help
+about the keys you can type inside the virtual serial console. In
+particular, use @key{Ctrl-a x} to exit QEMU and use @key{Ctrl-a b} as
+the Magic SysRq key.
+
+@item
+If the network is enabled, launch the script @file{/etc/linuxrc} in the
+emulator (don't forget the leading dot):
+@example
+. /etc/linuxrc
+@end example
+
+Then enable X11 connections on your PC from the emulated Linux:
+@example
+xhost +172.20.0.2
+@end example
+
+You can now launch @file{xterm} or @file{xlogo} and verify that you have
+a real Virtual Linux system !
+
+@end enumerate
+
+NOTES:
+@enumerate
+@item
+A 2.5.66 kernel is also included in the vl-test archive. Just
+replace the bzImage in vl.sh to try it.
+
+@item
+vl creates a temporary file in @var{$VLTMPDIR} (@file{/tmp} is the
+default) containing all the simulated PC memory. If possible, try to use
+a temporary directory using the tmpfs filesystem to avoid too many
+unnecessary disk accesses.
+
+@item
+The example initrd is a modified version of the one made by Kevin
+Lawton for the plex86 Project (@url{www.plex86.org}).
+
+@end enumerate
+
+@section Kernel Compilation
+
+You can use any Linux kernel within QEMU provided it is mapped at
+address 0x90000000 (the default is 0xc0000000). You must modify only two
+lines in the kernel source:
+
+In asm/page.h, replace
+@example
+#define __PAGE_OFFSET (0xc0000000)
+@end example
+by
+@example
+#define __PAGE_OFFSET (0x90000000)
@end example
+And in arch/i386/vmlinux.lds, replace
+@example
+ . = 0xc0000000 + 0x100000;
+@end example
+by
+@example
+ . = 0x90000000 + 0x100000;
+@end example
+
+The file config-2.4.20 gives the configuration of the example kernel.
+
+Just type
+@example
+make bzImage
+@end example
+
+As you would do to make a real kernel. Then you can use with QEMU
+exactly the same kernel as you would boot on your PC (in
+@file{arch/i386/boot/bzImage}).
+
+If you are not using a 2.5 kernel as host kernel but if you use a target
+2.5 kernel, you must also ensure that the 'HZ' define is set to 100
+(1000 is the default) as QEMU cannot currently emulate timers at
+frequencies greater than 100 Hz on host Linux systems < 2.5. In
+asm/param.h, replace:
+
+@example
+# define HZ 1000 /* Internal kernel timer frequency */
+@end example
+by
+@example
+# define HZ 100 /* Internal kernel timer frequency */
+@end example
+
+If you have problems running your kernel, verify that neither the SMP nor
+HIGHMEM configuration options are activated.
+
+@section PC Emulation
+
+QEMU emulates the following PC peripherials:
+
+@itemize
+@item
+PIC (interrupt controler)
+@item
+PIT (timers)
+@item
+CMOS memory
+@item
+Serial port (port=0x3f8, irq=4)
+@item
+NE2000 network adapter (port=0x300, irq=9)
+@item
+Dumb VGA (to print the @code{Uncompressing Linux} message)
+@end itemize
+
+@section GDB usage
+
+QEMU has a primitive support to work with gdb, so that you can do
+'Ctrl-C' while the kernel is running and inspect its state.
+
+In order to use gdb, launch vl with the '-s' option. It will wait for a
+gdb connection:
+@example
+> vl -s arch/i386/boot/bzImage initrd-2.4.20.img root=/dev/ram0 ramdisk_size=6144
+Connected to host network interface: tun0
+Waiting gdb connection on port 1234
+@end example
+
+Then launch gdb on the 'vmlinux' executable:
+@example
+> gdb vmlinux
+@end example
+
+In gdb, connect to QEMU:
+@example
+(gdb) target remote locahost:1234
+@end example
+
+Then you can use gdb normally. For example, type 'c' to launch the kernel:
+@example
+(gdb) c
+@end example
+
+WARNING: breakpoints and single stepping are not yet supported.
+
@chapter QEMU Internals
@section QEMU compared to other emulators
-Unlike bochs [3], QEMU emulates only a user space x86 CPU. It means that
-you cannot launch an operating system with it. The benefit is that it is
-simpler and faster due to the fact that some of the low level CPU state
-can be ignored (in particular, no virtual memory needs to be emulated).
+Like bochs [3], QEMU emulates an x86 CPU. But QEMU is much faster than
+bochs as it uses dynamic compilation and because it uses the host MMU to
+simulate the x86 MMU. The downside is that currently the emulation is
+not as accurate as bochs (for example, you cannot currently run Windows
+inside QEMU).
Like Valgrind [2], QEMU does user space emulation and dynamic
translation. Valgrind is mainly a memory debugger while QEMU has no
-support for it (QEMU could be used to detect out of bound memory accesses
-as Valgrind, but it has no support to track uninitialised data as
-Valgrind does). Valgrind dynamic translator generates better code than
-QEMU (in particular it does register allocation) but it is closely tied
-to an x86 host.
-
-EM86 [4] is the closest project to QEMU (and QEMU still uses some of its
-code, in particular the ELF file loader). EM86 was limited to an alpha
-host and used a proprietary and slow interpreter (the interpreter part
-of the FX!32 Digital Win32 code translator [5]).
+support for it (QEMU could be used to detect out of bound memory
+accesses as Valgrind, but it has no support to track uninitialised data
+as Valgrind does). The Valgrind dynamic translator generates better code
+than QEMU (in particular it does register allocation) but it is closely
+tied to an x86 host and target and has no support for precise exceptions
+and system emulation.
+
+EM86 [4] is the closest project to user space QEMU (and QEMU still uses
+some of its code, in particular the ELF file loader). EM86 was limited
+to an alpha host and used a proprietary and slow interpreter (the
+interpreter part of the FX!32 Digital Win32 code translator [5]).
+
+TWIN [6] is a Windows API emulator like Wine. It is less accurate than
+Wine but includes a protected mode x86 interpreter to launch x86 Windows
+executables. Such an approach as greater potential because most of the
+Windows API is executed natively but it is far more difficult to develop
+because all the data structures and function parameters exchanged
+between the API and the x86 code must be converted.
+
+User mode Linux [7] was the only solution before QEMU to launch a Linux
+kernel as a process while not needing any host kernel patches. However,
+user mode Linux requires heavy kernel patches while QEMU accepts
+unpatched Linux kernels. It would be interesting to compare the
+performance of the two approaches.
+
+The new Plex86 [8] PC virtualizer is done in the same spirit as the QEMU
+system emulator. It requires a patched Linux kernel to work (you cannot
+launch the same kernel on your PC), but the patches are really small. As
+it is a PC virtualizer (no emulation is done except for some priveledged
+instructions), it has the potential of being faster than QEMU. The
+downside is that a complicated (and potentially unsafe) host kernel
+patch is needed.
@section Portable dynamic translation
QEMU is a dynamic translator. When it first encounters a piece of code,
it converts it to the host instruction set. Usually dynamic translators
-are very complicated and highly CPU dependant. QEMU uses some tricks
+are very complicated and highly CPU dependent. QEMU uses some tricks
which make it relatively easily portable and simple while achieving good
performances.
Good CPU condition codes emulation (@code{EFLAGS} register on x86) is a
critical point to get good performances. QEMU uses lazy condition code
evaluation: instead of computing the condition codes after each x86
-instruction, it store justs one operand (called @code{CC_CRC}), the
+instruction, it just stores one operand (called @code{CC_SRC}), the
result (called @code{CC_DST}) and the type of operation (called
@code{CC_OP}).
the condition codes are not needed by the next instructions, no
condition codes are computed at all.
-@section Translation CPU state optimisations
+@section CPU state optimisations
The x86 CPU has many internal states which change the way it evaluates
instructions. In order to achieve a good speed, the translation phase
terminated by a jump or by a virtual CPU state change which the
translator cannot deduce statically).
-[Currently, the translated code is not patched if it jumps to another
-translated code].
+@section Direct block chaining
+
+After each translated basic block is executed, QEMU uses the simulated
+Program Counter (PC) and other cpu state informations (such as the CS
+segment base value) to find the next basic block.
+
+In order to accelerate the most common cases where the new simulated PC
+is known, QEMU can patch a basic block so that it jumps directly to the
+next one.
+
+The most portable code uses an indirect jump. An indirect jump makes it
+easier to make the jump target modification atomic. On some
+architectures (such as PowerPC), the @code{JUMP} opcode is directly
+patched so that the block chaining has no overhead.
+
+@section Self-modifying code and translated code invalidation
+
+Self-modifying code is a special challenge in x86 emulation because no
+instruction cache invalidation is signaled by the application when code
+is modified.
+
+When translated code is generated for a basic block, the corresponding
+host page is write protected if it is not already read-only (with the
+system call @code{mprotect()}). Then, if a write access is done to the
+page, Linux raises a SEGV signal. QEMU then invalidates all the
+translated code in the page and enables write accesses to the page.
+
+Correct translated code invalidation is done efficiently by maintaining
+a linked list of every translated block contained in a given page. Other
+linked lists are also maintained to undo direct block chaining.
+
+Althought the overhead of doing @code{mprotect()} calls is important,
+most MSDOS programs can be emulated at reasonnable speed with QEMU and
+DOSEMU.
+
+Note that QEMU also invalidates pages of translated code when it detects
+that memory mappings are modified with @code{mmap()} or @code{munmap()}.
@section Exception support
longjmp() is used when an exception such as division by zero is
-encountered. The host SIGSEGV and SIGBUS signal handlers are used to get
-invalid memory accesses.
+encountered.
-[Currently, the virtual CPU cannot retrieve the exact CPU state in some
-exceptions, although it could except for the @code{EFLAGS} register].
+The host SIGSEGV and SIGBUS signal handlers are used to get invalid
+memory accesses. The exact CPU state can be retrieved because all the
+x86 registers are stored in fixed host registers. The simulated program
+counter is found by retranslating the corresponding basic block and by
+looking where the host program counter was at the exception point.
+
+The virtual CPU cannot retrieve the exact @code{EFLAGS} register because
+in some cases it is not computed because of condition code
+optimisations. It is not a big concern because the emulated code can
+still be restarted in any cases.
@section Linux system call translation
endianness and 32/64 bit issues. The IOCTLs are converted with a generic
type description system (see @file{ioctls.h} and @file{thunk.c}).
+QEMU supports host CPUs which have pages bigger than 4KB. It records all
+the mappings the process does and try to emulated the @code{mmap()}
+system calls in cases where the host @code{mmap()} call would fail
+because of bad page alignment.
+
@section Linux signals
Normal and real-time signals are queued along with their information
The virtual x86 CPU atomic operations are emulated with a global lock so
that their semantic is preserved.
+Note that currently there are still some locking issues in QEMU. In
+particular, the translated cache flush is not protected yet against
+reentrancy.
+
+@section Self-virtualization
+
+QEMU was conceived so that ultimately it can emulate itself. Althought
+it is not very useful, it is an important test to show the power of the
+emulator.
+
+Achieving self-virtualization is not easy because there may be address
+space conflicts. QEMU solves this problem by being an executable ELF
+shared object as the ld-linux.so ELF interpreter. That way, it can be
+relocated at load time.
+
+@section MMU emulation
+
+For system emulation, QEMU uses the mmap() system call to emulate the
+target CPU MMU. It works as long the emulated OS does not use an area
+reserved by the host OS (such as the area above 0xc0000000 on x86
+Linux).
+
+It is planned to add a slower but more precise MMU emulation
+with a software MMU.
+
@section Bibliography
@table @asis
DIGITAL FX!32: Running 32-Bit x86 Applications on Alpha NT, by Anton
Chernoff and Ray Hookway.
+@item [6]
+@url{http://www.willows.com/}, Windows API library emulation from
+Willows Software.
+
+@item [7]
+@url{http://user-mode-linux.sourceforge.net/},
+The User-mode Linux Kernel.
+
+@item [8]
+@url{http://www.plex86.org/},
+The new Plex86 project.
+
@end table
@chapter Regression Tests
-In the directory @file{tests/}, various interesting x86 testing programs
+In the directory @file{tests/}, various interesting testing programs
are available. There are used for regression testing.
-@section @file{hello}
+@section @file{hello-i386}
Very simple statically linked x86 program, just to test QEMU during a
port to a new host CPU.
+@section @file{hello-arm}
+
+Very simple statically linked ARM program, just to test QEMU during a
+port to a new host CPU.
+
@section @file{test-i386}
This program executes most of the 16 bit and 32 bit x86 instructions and
The Linux system call @code{modify_ldt()} is used to create x86 selectors
to test some 16 bit addressing and 32 bit with segmentation cases.
-@section @file{testsig}
-
-This program tests various signal cases, including SIGFPE, SIGSEGV and
-SIGILL.
-
-@section @file{testclone}
-
-Tests the @code{clone()} system call (basic test).
-
-@section @file{testthread}
+The Linux system call @code{vm86()} is used to test vm86 emulation.
-Tests the glibc threads (more complicated than @code{clone()} because signals
-are also used).
+Various exceptions are raised to test most of the x86 user space
+exception reporting.
@section @file{sha1}