diff options
| -rw-r--r-- | Makefile | 4 | ||||
| -rw-r--r-- | TODO | 1 | ||||
| -rw-r--r-- | linux-2.6-qemu-fast.patch | 305 | ||||
| -rw-r--r-- | qemu-doc.texi | 1138 | ||||
| -rw-r--r-- | qemu-tech.texi | 506 |
5 files changed, 1293 insertions, 661 deletions
@@ -11,7 +11,7 @@ ifndef CONFIG_WIN32 TOOLS=qemu-mkcow endif -all: dyngen$(EXESUF) $(TOOLS) qemu-doc.html qemu.1 +all: dyngen$(EXESUF) $(TOOLS) qemu-doc.html qemu-tech.html qemu.1 for d in $(TARGET_DIRS); do \ make -C $$d $@ || exit 1 ; \ done @@ -61,7 +61,7 @@ TAGS: etags *.[ch] tests/*.[ch] # documentation -qemu-doc.html: qemu-doc.texi +%.html: %.texi texi2html -monolithic -number $< qemu.1: qemu-doc.texi @@ -2,7 +2,6 @@ short term: ---------- - handle fast timers + add explicit clocks - OS/2 install bug -- win 95 install bug - handle Self Modifying Code even if modifying current TB (BE OS 5 install) - physical memory cache (reduce qemu-fast address space size to about 32 MB) - better code fetch diff --git a/linux-2.6-qemu-fast.patch b/linux-2.6-qemu-fast.patch new file mode 100644 index 0000000000..34ca5a232e --- /dev/null +++ b/linux-2.6-qemu-fast.patch @@ -0,0 +1,305 @@ +diff -urpN --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal .32324-linux-2.6.0/arch/i386/Kconfig .32324-linux-2.6.0.updated/arch/i386/Kconfig +--- .32324-linux-2.6.0/arch/i386/Kconfig 2003-10-09 18:02:48.000000000 +1000 ++++ .32324-linux-2.6.0.updated/arch/i386/Kconfig 2003-12-26 16:46:49.000000000 +1100 +@@ -307,6 +307,14 @@ config X86_GENERIC + when it has moderate overhead. This is intended for generic + distributions kernels. + ++config QEMU ++ bool "Kernel to run under QEMU" ++ depends on EXPERIMENTAL ++ help ++ Select this if you want to boot the kernel inside qemu-fast, ++ the non-mmu version of the x86 emulator. See ++ <http://fabrice.bellard.free.fr/qemu/>. Say N. ++ + # + # Define implied options from the CPU selection here + # +diff -urpN --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal .32324-linux-2.6.0/arch/i386/kernel/Makefile .32324-linux-2.6.0.updated/arch/i386/kernel/Makefile +--- .32324-linux-2.6.0/arch/i386/kernel/Makefile 2003-09-29 10:25:15.000000000 +1000 ++++ .32324-linux-2.6.0.updated/arch/i386/kernel/Makefile 2003-12-26 16:46:49.000000000 +1100 +@@ -46,12 +46,14 @@ quiet_cmd_syscall = SYSCALL $@ + cmd_syscall = $(CC) -nostdlib $(SYSCFLAGS_$(@F)) \ + -Wl,-T,$(filter-out FORCE,$^) -o $@ + ++export AFLAGS_vsyscall.lds.o += -P -C -U$(ARCH) ++ + vsyscall-flags = -shared -s -Wl,-soname=linux-gate.so.1 + SYSCFLAGS_vsyscall-sysenter.so = $(vsyscall-flags) + SYSCFLAGS_vsyscall-int80.so = $(vsyscall-flags) + + $(obj)/vsyscall-int80.so $(obj)/vsyscall-sysenter.so: \ +-$(obj)/vsyscall-%.so: $(src)/vsyscall.lds $(obj)/vsyscall-%.o FORCE ++$(obj)/vsyscall-%.so: $(src)/vsyscall.lds.s $(obj)/vsyscall-%.o FORCE + $(call if_changed,syscall) + + # We also create a special relocatable object that should mirror the symbol +@@ -62,5 +64,5 @@ $(obj)/built-in.o: $(obj)/vsyscall-syms. + $(obj)/built-in.o: ld_flags += -R $(obj)/vsyscall-syms.o + + SYSCFLAGS_vsyscall-syms.o = -r +-$(obj)/vsyscall-syms.o: $(src)/vsyscall.lds $(obj)/vsyscall-sysenter.o FORCE ++$(obj)/vsyscall-syms.o: $(src)/vsyscall.lds.s $(obj)/vsyscall-sysenter.o FORCE + $(call if_changed,syscall) +diff -urpN --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal .32324-linux-2.6.0/arch/i386/kernel/vmlinux.lds.S .32324-linux-2.6.0.updated/arch/i386/kernel/vmlinux.lds.S +--- .32324-linux-2.6.0/arch/i386/kernel/vmlinux.lds.S 2003-09-22 10:27:28.000000000 +1000 ++++ .32324-linux-2.6.0.updated/arch/i386/kernel/vmlinux.lds.S 2003-12-26 16:46:49.000000000 +1100 +@@ -3,6 +3,7 @@ + */ + + #include <asm-generic/vmlinux.lds.h> ++#include <asm/page.h> + + OUTPUT_FORMAT("elf32-i386", "elf32-i386", "elf32-i386") + OUTPUT_ARCH(i386) +@@ -10,7 +11,7 @@ ENTRY(startup_32) + jiffies = jiffies_64; + SECTIONS + { +- . = 0xC0000000 + 0x100000; ++ . = __PAGE_OFFSET + 0x100000; + /* read-only */ + _text = .; /* Text and read-only data */ + .text : { +diff -urpN --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal .32324-linux-2.6.0/arch/i386/kernel/vsyscall.lds .32324-linux-2.6.0.updated/arch/i386/kernel/vsyscall.lds +--- .32324-linux-2.6.0/arch/i386/kernel/vsyscall.lds 2003-09-22 10:07:26.000000000 +1000 ++++ .32324-linux-2.6.0.updated/arch/i386/kernel/vsyscall.lds 1970-01-01 10:00:00.000000000 +1000 +@@ -1,67 +0,0 @@ +-/* +- * Linker script for vsyscall DSO. The vsyscall page is an ELF shared +- * object prelinked to its virtual address, and with only one read-only +- * segment (that fits in one page). This script controls its layout. +- */ +- +-/* This must match <asm/fixmap.h>. */ +-VSYSCALL_BASE = 0xffffe000; +- +-SECTIONS +-{ +- . = VSYSCALL_BASE + SIZEOF_HEADERS; +- +- .hash : { *(.hash) } :text +- .dynsym : { *(.dynsym) } +- .dynstr : { *(.dynstr) } +- .gnu.version : { *(.gnu.version) } +- .gnu.version_d : { *(.gnu.version_d) } +- .gnu.version_r : { *(.gnu.version_r) } +- +- /* This linker script is used both with -r and with -shared. +- For the layouts to match, we need to skip more than enough +- space for the dynamic symbol table et al. If this amount +- is insufficient, ld -shared will barf. Just increase it here. */ +- . = VSYSCALL_BASE + 0x400; +- +- .text : { *(.text) } :text =0x90909090 +- +- .eh_frame_hdr : { *(.eh_frame_hdr) } :text :eh_frame_hdr +- .eh_frame : { KEEP (*(.eh_frame)) } :text +- .dynamic : { *(.dynamic) } :text :dynamic +- .useless : { +- *(.got.plt) *(.got) +- *(.data .data.* .gnu.linkonce.d.*) +- *(.dynbss) +- *(.bss .bss.* .gnu.linkonce.b.*) +- } :text +-} +- +-/* +- * We must supply the ELF program headers explicitly to get just one +- * PT_LOAD segment, and set the flags explicitly to make segments read-only. +- */ +-PHDRS +-{ +- text PT_LOAD FILEHDR PHDRS FLAGS(5); /* PF_R|PF_X */ +- dynamic PT_DYNAMIC FLAGS(4); /* PF_R */ +- eh_frame_hdr 0x6474e550; /* PT_GNU_EH_FRAME, but ld doesn't match the name */ +-} +- +-/* +- * This controls what symbols we export from the DSO. +- */ +-VERSION +-{ +- LINUX_2.5 { +- global: +- __kernel_vsyscall; +- __kernel_sigreturn; +- __kernel_rt_sigreturn; +- +- local: *; +- }; +-} +- +-/* The ELF entry point can be used to set the AT_SYSINFO value. */ +-ENTRY(__kernel_vsyscall); +diff -urpN --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal .32324-linux-2.6.0/arch/i386/kernel/vsyscall.lds.S .32324-linux-2.6.0.updated/arch/i386/kernel/vsyscall.lds.S +--- .32324-linux-2.6.0/arch/i386/kernel/vsyscall.lds.S 1970-01-01 10:00:00.000000000 +1000 ++++ .32324-linux-2.6.0.updated/arch/i386/kernel/vsyscall.lds.S 2003-12-26 16:46:49.000000000 +1100 +@@ -0,0 +1,67 @@ ++/* ++ * Linker script for vsyscall DSO. The vsyscall page is an ELF shared ++ * object prelinked to its virtual address, and with only one read-only ++ * segment (that fits in one page). This script controls its layout. ++ */ ++#include <asm/fixmap.h> ++ ++VSYSCALL_BASE = __FIXADDR_TOP - 0x1000; ++ ++SECTIONS ++{ ++ . = VSYSCALL_BASE + SIZEOF_HEADERS; ++ ++ .hash : { *(.hash) } :text ++ .dynsym : { *(.dynsym) } ++ .dynstr : { *(.dynstr) } ++ .gnu.version : { *(.gnu.version) } ++ .gnu.version_d : { *(.gnu.version_d) } ++ .gnu.version_r : { *(.gnu.version_r) } ++ ++ /* This linker script is used both with -r and with -shared. ++ For the layouts to match, we need to skip more than enough ++ space for the dynamic symbol table et al. If this amount ++ is insufficient, ld -shared will barf. Just increase it here. */ ++ . = VSYSCALL_BASE + 0x400; ++ ++ .text : { *(.text) } :text =0x90909090 ++ ++ .eh_frame_hdr : { *(.eh_frame_hdr) } :text :eh_frame_hdr ++ .eh_frame : { KEEP (*(.eh_frame)) } :text ++ .dynamic : { *(.dynamic) } :text :dynamic ++ .useless : { ++ *(.got.plt) *(.got) ++ *(.data .data.* .gnu.linkonce.d.*) ++ *(.dynbss) ++ *(.bss .bss.* .gnu.linkonce.b.*) ++ } :text ++} ++ ++/* ++ * We must supply the ELF program headers explicitly to get just one ++ * PT_LOAD segment, and set the flags explicitly to make segments read-only. ++ */ ++PHDRS ++{ ++ text PT_LOAD FILEHDR PHDRS FLAGS(5); /* PF_R|PF_X */ ++ dynamic PT_DYNAMIC FLAGS(4); /* PF_R */ ++ eh_frame_hdr 0x6474e550; /* PT_GNU_EH_FRAME, but ld doesn't match the name */ ++} ++ ++/* ++ * This controls what symbols we export from the DSO. ++ */ ++VERSION ++{ ++ LINUX_2.5 { ++ global: ++ __kernel_vsyscall; ++ __kernel_sigreturn; ++ __kernel_rt_sigreturn; ++ ++ local: *; ++ }; ++} ++ ++/* The ELF entry point can be used to set the AT_SYSINFO value. */ ++ENTRY(__kernel_vsyscall); +diff -urpN --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal .32324-linux-2.6.0/include/asm-i386/fixmap.h .32324-linux-2.6.0.updated/include/asm-i386/fixmap.h +--- .32324-linux-2.6.0/include/asm-i386/fixmap.h 2003-09-22 10:09:12.000000000 +1000 ++++ .32324-linux-2.6.0.updated/include/asm-i386/fixmap.h 2003-12-26 16:46:49.000000000 +1100 +@@ -14,6 +14,19 @@ + #define _ASM_FIXMAP_H + + #include <linux/config.h> ++ ++/* used by vmalloc.c, vsyscall.lds.S. ++ * ++ * Leave one empty page between vmalloc'ed areas and ++ * the start of the fixmap. ++ */ ++#ifdef CONFIG_QEMU ++#define __FIXADDR_TOP 0xa7fff000 ++#else ++#define __FIXADDR_TOP 0xfffff000 ++#endif ++ ++#ifndef __ASSEMBLY__ + #include <linux/kernel.h> + #include <asm/acpi.h> + #include <asm/apicdef.h> +@@ -94,13 +107,8 @@ extern void __set_fixmap (enum fixed_add + #define clear_fixmap(idx) \ + __set_fixmap(idx, 0, __pgprot(0)) + +-/* +- * used by vmalloc.c. +- * +- * Leave one empty page between vmalloc'ed areas and +- * the start of the fixmap. +- */ +-#define FIXADDR_TOP (0xfffff000UL) ++#define FIXADDR_TOP ((unsigned long)__FIXADDR_TOP) ++ + #define __FIXADDR_SIZE (__end_of_permanent_fixed_addresses << PAGE_SHIFT) + #define FIXADDR_START (FIXADDR_TOP - __FIXADDR_SIZE) + +@@ -145,4 +153,5 @@ static inline unsigned long virt_to_fix( + return __virt_to_fix(vaddr); + } + ++#endif /* !__ASSEMBLY__ */ + #endif +diff -urpN --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal .32324-linux-2.6.0/include/asm-i386/page.h .32324-linux-2.6.0.updated/include/asm-i386/page.h +--- .32324-linux-2.6.0/include/asm-i386/page.h 2003-09-22 10:06:42.000000000 +1000 ++++ .32324-linux-2.6.0.updated/include/asm-i386/page.h 2003-12-26 16:46:49.000000000 +1100 +@@ -10,10 +10,10 @@ + #define LARGE_PAGE_SIZE (1UL << PMD_SHIFT) + + #ifdef __KERNEL__ +-#ifndef __ASSEMBLY__ +- + #include <linux/config.h> + ++#ifndef __ASSEMBLY__ ++ + #ifdef CONFIG_X86_USE_3DNOW + + #include <asm/mmx.h> +@@ -115,12 +115,19 @@ static __inline__ int get_order(unsigned + #endif /* __ASSEMBLY__ */ + + #ifdef __ASSEMBLY__ ++#ifdef CONFIG_QEMU ++#define __PAGE_OFFSET (0x90000000) ++#else + #define __PAGE_OFFSET (0xC0000000) ++#endif /* QEMU */ ++#else ++#ifdef CONFIG_QEMU ++#define __PAGE_OFFSET (0x90000000UL) + #else + #define __PAGE_OFFSET (0xC0000000UL) ++#endif /* QEMU */ + #endif + +- + #define PAGE_OFFSET ((unsigned long)__PAGE_OFFSET) + #define VMALLOC_RESERVE ((unsigned long)__VMALLOC_RESERVE) + #define MAXMEM (-__PAGE_OFFSET-__VMALLOC_RESERVE) +diff -urpN --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal .32324-linux-2.6.0/include/asm-i386/param.h .32324-linux-2.6.0.updated/include/asm-i386/param.h +--- .32324-linux-2.6.0/include/asm-i386/param.h 2003-09-21 17:26:06.000000000 +1000 ++++ .32324-linux-2.6.0.updated/include/asm-i386/param.h 2003-12-26 16:46:49.000000000 +1100 +@@ -2,7 +2,12 @@ + #define _ASMi386_PARAM_H + + #ifdef __KERNEL__ +-# define HZ 1000 /* Internal kernel timer frequency */ ++# include <linux/config.h> ++# ifdef CONFIG_QEMU ++# define HZ 100 ++# else ++# define HZ 1000 /* Internal kernel timer frequency */ ++# endif + # define USER_HZ 100 /* .. some user interfaces are in "ticks" */ + # define CLOCKS_PER_SEC (USER_HZ) /* like times() */ + #endif diff --git a/qemu-doc.texi b/qemu-doc.texi index 5ca8e8f3bb..1f056065bd 100644 --- a/qemu-doc.texi +++ b/qemu-doc.texi @@ -1,10 +1,10 @@ \input texinfo @c -*- texinfo -*- @iftex -@settitle QEMU CPU Emulator Reference Documentation +@settitle QEMU CPU Emulator User Documentation @titlepage @sp 7 -@center @titlefont{QEMU CPU Emulator Reference Documentation} +@center @titlefont{QEMU CPU Emulator User Documentation} @sp 3 @end titlepage @end iftex @@ -13,126 +13,39 @@ @section 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. +QEMU is a FAST! processor emulator using dynamic translation to +achieve good emulation speed. QEMU has two operating modes: @itemize @minus @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{http://www.dosemu.org}) are the main targets for QEMU. +Full system emulation. In this mode, QEMU emulates a full system (for +example a PC), including a processor and various peripherials. It can +be used to launch different Operating Systems without rebooting the +PC or to debug system code. @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. +User mode emulation (Linux host only). In this mode, QEMU can launch +Linux processes compiled for one CPU on another CPU. It can be used to +launch the Wine Windows API emulator (@url{http://www.winehq.org}) or +to ease cross-compilation and cross-debugging. @end itemize -As QEMU requires no host kernel patches to run, it is very safe and +As QEMU requires no host kernel driver to run, it is very safe and easy to use. -QEMU generic features: +For system emulation, only the x86 PC emulator is currently +usable. The PowerPC system emulator is being developped. -@itemize - -@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 Precise exceptions support. - -@item The virtual CPU is a library (@code{libqemu}) which can be used -in other projects. - -@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 QEMU can either use a full software MMU for maximum portability or use the host system call mmap() to simulate the target MMU. -@end itemize - -@section x86 emulation - -QEMU x86 target features: - -@itemize - -@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. - -@end itemize - -Current QEMU limitations: - -@itemize - -@item No SSE/MMX support (yet). - -@item No x86-64 support. - -@item IPC syscalls are missing. - -@item The x86 segment limits and access rights are not tested at every -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 Some priviledged instructions or behaviors are missing, especially for segment protection testing (yet). - -@end itemize - -@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 - -@section SPARC emulation - -The SPARC emulation is currently in development. +For user emulation, x86, PowerPC, ARM, and SPARC CPUs are supported. @chapter Installation +@section Linux + If you want to compile QEMU, please read the @file{README} which gives the related information. Otherwise just download the binary distribution (@file{qemu-XXX-i386.tar.gz}) and untar it as root in @@ -144,106 +57,69 @@ cd / tar zxvf /tmp/qemu-XXX-i386.tar.gz @end example -@chapter QEMU User space emulator invocation - -@section Quick Start - -In order to launch a Linux process, QEMU needs the process executable -itself and all the target (x86) dynamic libraries used by it. - +@section Windows +w @itemize +@item Install the current versions of MSYS and MinGW from +@url{http://www.mingw.org/}. You can find detailed installation +instructions in the download section and the FAQ. + +@item Download +the MinGW development library of SDL 1.2.x +(@file{SDL-devel-1.2.x-mingw32.tar.gz}) from +@url{http://www.libsdl.org}. Unpack it in a temporary place, and +unpack the archive @file{i386-mingw32msvc.tar.gz} in the MinGW tool +directory. Edit the @file{sdl-config} script so that it gives the +correct SDL directory when invoked. + +@item Extract the current version of QEMU. + +@item Start the MSYS shell (file @file{msys.bat}). -@item On x86, you can just try to launch any process by using the native -libraries: - -@example -qemu-i386 -L / /bin/ls -@end example - -@code{-L /} tells that the x86 dynamic linker must be searched with a -@file{/} prefix. - -@item Since QEMU is also a linux process, you can launch qemu with qemu (NOTE: you can only do that if you compiled QEMU from the sources): - -@example -qemu-i386 -L / qemu-i386 -L / /bin/ls -@end example - -@item On non x86 CPUs, you need first to download at least an x86 glibc -(@file{qemu-runtime-i386-XXX-.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-i386 tests/i386/ls -@end example -You can look at @file{qemu-binfmt-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 Change to the QEMU directory. Launch @file{./configure} and +@file{make}. If you have problems using SDL, verify that +@file{sdl-config} can be launched from the MSYS command line. -@item The x86 version of QEMU is also included. You can try weird things such as: -@example -qemu-i386 /usr/local/qemu-i386/bin/qemu-i386 /usr/local/qemu-i386/bin/ls-i386 -@end example +@item You can install QEMU in @file{Program Files/Qemu} by typing +@file{make install}. Don't forget to copy @file{SDL.dll} in +@file{Program Files/Qemu}. @end itemize -@section Wine launch +@section Cross compilation for Windows with Linux @itemize +@item +Install the MinGW cross compilation tools available at +@url{http://www.mingw.org/}. -@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: +@item +Install the Win32 version of SDL (@url{http://www.libsdl.org}) by +unpacking @file{i386-mingw32msvc.tar.gz}. Set up the PATH environment +variable so that @file{i386-mingw32msvc-sdl-config} can be launched by +the QEMU configuration script. +@item +Configure QEMU for Windows cross compilation: @example -qemu-i386 /usr/local/qemu-i386/bin/ls-i386 +./configure --enable-mingw32 @end example +If necessary, you can change the cross-prefix according to the prefix +choosen for the MinGW tools with --cross-prefix. You can also use +--prefix to set the Win32 install path. -@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-i386 /usr/local/qemu-i386/wine/bin/wine /usr/local/qemu-i386/wine/c/Program\ Files/putty.exe -@end example +@item You can install QEMU in the installation directory by typing +@file{make install}. Don't forget to copy @file{SDL.dll} in the +installation directory. @end itemize -@section Command line options +Note: Currently, Wine does not seem able to launch +QEMU for Win32. -@example -usage: qemu-i386 [-h] [-d] [-L path] [-s size] program [arguments...] -@end example +@section Mac OS X -@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 +Mac OS X is currently not supported. @chapter QEMU System emulator invocation @@ -251,9 +127,7 @@ Act as if the host page size was 'pagesize' bytes @c man begin DESCRIPTION -The QEMU System emulator simulates a complete PC. It can either boot -directly a Linux kernel (without any BIOS or boot loader) or boot like a -real PC with the included BIOS. +The QEMU System emulator simulates a complete PC. In order to meet specific user needs, two versions of QEMU are available: @@ -282,18 +156,14 @@ VGA (hardware level, including all non standard modes) PS/2 mouse and keyboard @item 2 IDE interfaces with hard disk and CD-ROM support +@item +Floppy disk @item -NE2000 network adapter (port=0x300, irq=9) +up to 6 NE2000 network adapters @item Serial port @item Soundblaster 16 card -@item -PIC (interrupt controler) -@item -PIT (timers) -@item -CMOS memory @end itemize @c man end @@ -308,157 +178,6 @@ qemu linux.img Linux should boot and give you a prompt. -@section Direct Linux Boot and Network emulation - -This section explains how to launch a Linux kernel inside QEMU without -having to make a full bootable image. It is very useful for fast Linux -kernel testing. The QEMU network configuration is also explained. - -@enumerate -@item -Download the archive @file{linux-test-xxx.tar.gz} containing a Linux -kernel and a disk image. - -@item Optional: If you want network support (for example to launch X11 examples), you -must copy the script @file{qemu-ifup} in @file{/etc} and configure -properly @code{sudo} so that the command @code{ifconfig} contained in -@file{qemu-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{qemu.sh}. You should have the following output: - -@example -> ./qemu.sh -Connected to host network interface: tun0 -Linux version 2.4.21 (bellard@voyager.localdomain) (gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)) #5 Tue Nov 11 18:18:53 CET 2003 -BIOS-provided physical RAM map: - BIOS-e801: 0000000000000000 - 000000000009f000 (usable) - BIOS-e801: 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/hda sb=0x220,5,1,5 ide2=noprobe ide3=noprobe ide4=noprobe ide5=noprobe console=ttyS0 -ide_setup: ide2=noprobe -ide_setup: ide3=noprobe -ide_setup: ide4=noprobe -ide_setup: ide5=noprobe -Initializing CPU#0 -Detected 2399.621 MHz processor. -Console: colour EGA 80x25 -Calibrating delay loop... 4744.80 BogoMIPS -Memory: 28872k/32768k available (1210k kernel code, 3508k reserved, 266k data, 64k 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 -Journalled Block Device driver loaded -Detected PS/2 Mouse Port. -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 4096K size 1024 blocksize -Uniform Multi-Platform E-IDE driver Revision: 7.00beta4-2.4 -ide: Assuming 50MHz system bus speed for PIO modes; override with idebus=xx -hda: QEMU HARDDISK, ATA DISK drive -ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 -hda: attached ide-disk driver. -hda: 20480 sectors (10 MB) w/256KiB Cache, CHS=20/16/63 -Partition check: - hda: -Soundblaster audio driver Copyright (C) by Hannu Savolainen 1993-1996 -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 4096) -NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. -EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended -VFS: Mounted root (ext2 filesystem). -Freeing unused kernel memory: 64k freed - -Linux version 2.4.21 (bellard@voyager.localdomain) (gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)) #5 Tue Nov 11 18:18:53 CET 2003 - -QEMU Linux test distribution (based on Redhat 9) - -Type 'exit' to halt the system - -sh-2.05b# -@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.74 kernel is also included in the archive. Just -replace the bzImage in qemu.sh to try it. - -@item -qemu creates a temporary file in @var{$QEMU_TMPDIR} (@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 -In order to exit cleanly from qemu, you can do a @emph{shutdown} inside -qemu. qemu will automatically exit when the Linux shutdown is done. - -@item -You can boot slightly faster by disabling the probe of non present IDE -interfaces. To do so, add the following options on the kernel command -line: -@example -ide1=noprobe ide2=noprobe ide3=noprobe ide4=noprobe ide5=noprobe -@end example - -@item -The example disk image is a modified version of the one made by Kevin -Lawton for the plex86 Project (@url{www.plex86.org}). - -@end enumerate - @section Invocation @example @@ -486,8 +205,8 @@ Use @var{file} as hard disk 0, 1, 2 or 3 image (@xref{disk_images}). Use @var{file} as CD-ROM image (you cannot use @option{-hdc} and and @option{-cdrom} at the same time). -@item -boot [a|b|c|d] -Boot on floppy (a, b), hard disk (c) or CD-ROM (d). Hard disk boot is +@item -boot [a|c|d] +Boot on floppy (a), hard disk (c) or CD-ROM (d). Hard disk boot is the default. @item -snapshot @@ -498,19 +217,9 @@ the write back by pressing @key{C-a s} (@xref{disk_images}). @item -m megs Set virtual RAM size to @var{megs} megabytes. -@item -n script -Set network init script [default=/etc/qemu-ifup]. This script is -launched to configure the host network interface (usually tun0) -corresponding to the virtual NE2000 card. - @item -initrd file Use @var{file} as initial ram disk. -@item -tun-fd fd -Assumes @var{fd} talks to tap/tun and use it. Read -@url{http://bellard.org/qemu/tetrinet.html} to have an example of its -use. - @item -nographic Normally, QEMU uses SDL to display the VGA output. With this option, @@ -521,7 +230,35 @@ with a serial console. @end table -Linux boot specific (does not require a full PC boot with a BIOS): +Network options: + +@table @option + +@item -n script +Set network init script [default=/etc/qemu-ifup]. This script is +launched to configure the host network interface (usually tun0) +corresponding to the virtual NE2000 card. + +@item nics n +Simulate @var{n} network interfaces (default=1). + +@item -macaddr addr + +Set the mac address of the first interface (the format is +aa:bb:cc:dd:ee:ff in hexa). The mac address is incremented for each +new network interface. + +@item -tun-fd fd1,... +Assumes @var{fd} talks to tap/tun and use it. Read +@url{http://bellard.org/qemu/tetrinet.html} to have an example of its +use. + +@end table + +Linux boot specific. When using this options, you can use a given +Linux kernel without installing it in the disk image. It can be useful +for easier testing of various kernels. + @table @option @item -kernel bzImage @@ -545,7 +282,8 @@ Change gdb connection port. Output log in /tmp/qemu.log @end table -During emulation, use @key{C-a h} to get terminal commands: +During emulation, if you are using the serial console, use @key{C-a h} +to get terminal commands: @table @key @item C-a h @@ -555,7 +293,9 @@ Exit emulatior @item C-a s Save disk data back to file (if -snapshot) @item C-a b -Send break (magic sysrq) +Send break (magic sysrq in Linux) +@item C-a c +Switch between console and monitor @item C-a C-a Send C-a @end table @@ -578,6 +318,153 @@ Fabrice Bellard @end ignore @end ignore + + +@section QEMU Monitor + +The QEMU monitor is used to give complex commands to the QEMU +emulator. You can use it to: + +@itemize @minus + +@item +Remove or insert removable medias images +(such as CD-ROM or floppies) + +@item +Freeze/unfreeze the Virtual Machine (VM) and save or restore its state +from a disk file. + +@item Inspect the VM state without an external debugger. + +@end itemize + +@subsection Commands + +The following commands are available: + +@table @option + +@item help or ? [cmd] +Show the help for all commands or just for command @var{cmd}. + +@item commit +Commit changes to the disk images (if -snapshot is used) + +@item info subcommand +show various information about the system state + +@table @option +@item info network +show the network state +@item info block +show the block devices +@item info registers +show the cpu registers +@item info history +show the command line history +@end table + +@item q or quit +Quit the emulator. + +@item eject [-f] device +Eject a removable media (use -f to force it). + +@item change device filename +Change a removable media. + +@item screendump filename +Save screen into PPM image @var{filename}. + +@item log item1[,...] +Activate logging of the specified items to @file{/tmp/qemu.log}. + +@item savevm filename +Save the whole virtual machine state to @var{filename}. + +@item loadvm filename +Restore the whole virtual machine state from @var{filename}. + +@item stop +Stop emulation. + +@item c or cont +Resume emulation. + +@item gdbserver [port] +Start gdbserver session (default port=1234) + +@item x/fmt addr +Virtual memory dump starting at @var{addr}. + +@item xp /fmt addr +Physical memory dump starting at @var{addr}. + +@var{fmt} is a format which tells the command how to format the +data. Its syntax is: @option{/@{count@}@{format@}@{size@}} + +@table @var +@item count +is the number of items to be dumped. + +@item format +can be x (hexa), d (signed decimal), u (unsigned decimal), o (octal), +c (char) or i (asm instruction). + +@item size +can be b (8 bits), h (16 bits), w (32 bits) or g (64 bits) + +@end table + +Examples: +@itemize +@item +Dump 10 instructions at the current instruction pointer: +@example +(qemu) x/10i $eip +0x90107063: ret +0x90107064: sti +0x90107065: lea 0x0(%esi,1),%esi +0x90107069: lea 0x0(%edi,1),%edi +0x90107070: ret +0x90107071: jmp 0x90107080 +0x90107073: nop +0x90107074: nop +0x90107075: nop +0x90107076: nop +@end example + +@item +Dump 80 16 bit values at the start of the video memory. +@example +(qemu) xp/80hx 0xb8000 +0x000b8000: 0x0b50 0x0b6c 0x0b65 0x0b78 0x0b38 0x0b36 0x0b2f 0x0b42 +0x000b8010: 0x0b6f 0x0b63 0x0b68 0x0b73 0x0b20 0x0b56 0x0b47 0x0b41 +0x000b8020: 0x0b42 0x0b69 0x0b6f 0x0b73 0x0b20 0x0b63 0x0b75 0x0b72 +0x000b8030: 0x0b72 0x0b65 0x0b6e 0x0b74 0x0b2d 0x0b63 0x0b76 0x0b73 +0x000b8040: 0x0b20 0x0b30 0x0b35 0x0b20 0x0b4e 0x0b6f 0x0b76 0x0b20 +0x000b8050: 0x0b32 0x0b30 0x0b30 0x0b33 0x0720 0x0720 0x0720 0x0720 +0x000b8060: 0x0720 0x0720 0x0720 0x0720 0x0720 0x0720 0x0720 0x0720 +0x000b8070: 0x0720 0x0720 0x0720 0x0720 0x0720 0x0720 0x0720 0x0720 +0x000b8080: 0x0720 0x0720 0x0720 0x0720 0x0720 0x0720 0x0720 0x0720 +0x000b8090: 0x0720 0x0720 0x0720 0x0720 0x0720 0x0720 0x0720 0x0720 +@end example +@end itemize + +@item p or print/fmt expr + +Print expression value. Only the @var{format} part of @var{fmt} is +used. + +@end table + +@subsection Integer expressions + +The monitor understands integers expressions for every integer +argument. You can use register names to get the value of specifics +CPU registers by prefixing them with @emph{$}. + @node disk_images @section Disk Images @@ -649,13 +536,166 @@ Since holes are used, the displayed size of the COW disk image is not the real one. To know it, use the @code{ls -ls} command. @end enumerate +@section Direct Linux Boot and Network emulation + +This section explains how to launch a Linux kernel inside QEMU without +having to make a full bootable image. It is very useful for fast Linux +kernel testing. The QEMU network configuration is also explained. + +@enumerate +@item +Download the archive @file{linux-test-xxx.tar.gz} containing a Linux +kernel and a disk image. + +@item Optional: If you want network support (for example to launch X11 examples), you +must copy the script @file{qemu-ifup} in @file{/etc} and configure +properly @code{sudo} so that the command @code{ifconfig} contained in +@file{qemu-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{qemu.sh}. You should have the following output: + +@example +> ./qemu.sh +Connected to host network interface: tun0 +Linux version 2.4.21 (bellard@voyager.localdomain) (gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)) #5 Tue Nov 11 18:18:53 CET 2003 +BIOS-provided physical RAM map: + BIOS-e801: 0000000000000000 - 000000000009f000 (usable) + BIOS-e801: 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/hda sb=0x220,5,1,5 ide2=noprobe ide3=noprobe ide4=noprobe ide5=noprobe console=ttyS0 +ide_setup: ide2=noprobe +ide_setup: ide3=noprobe +ide_setup: ide4=noprobe +ide_setup: ide5=noprobe +Initializing CPU#0 +Detected 2399.621 MHz processor. +Console: colour EGA 80x25 +Calibrating delay loop... 4744.80 BogoMIPS +Memory: 28872k/32768k available (1210k kernel code, 3508k reserved, 266k data, 64k 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 +Journalled Block Device driver loaded +Detected PS/2 Mouse Port. +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 4096K size 1024 blocksize +Uniform Multi-Platform E-IDE driver Revision: 7.00beta4-2.4 +ide: Assuming 50MHz system bus speed for PIO modes; override with idebus=xx +hda: QEMU HARDDISK, ATA DISK drive +ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 +hda: attached ide-disk driver. +hda: 20480 sectors (10 MB) w/256KiB Cache, CHS=20/16/63 +Partition check: + hda: +Soundblaster audio driver Copyright (C) by Hannu Savolainen 1993-1996 +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 4096) +NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. +EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended +VFS: Mounted root (ext2 filesystem). +Freeing unused kernel memory: 64k freed + +Linux version 2.4.21 (bellard@voyager.localdomain) (gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)) #5 Tue Nov 11 18:18:53 CET 2003 + +QEMU Linux test distribution (based on Redhat 9) + +Type 'exit' to halt the system + +sh-2.05b# +@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.74 kernel is also included in the archive. Just +replace the bzImage in qemu.sh to try it. + +@item +qemu-fast creates a temporary file in @var{$QEMU_TMPDIR} (@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 +In order to exit cleanly from qemu, you can do a @emph{shutdown} inside +qemu. qemu will automatically exit when the Linux shutdown is done. + +@item +You can boot slightly faster by disabling the probe of non present IDE +interfaces. To do so, add the following options on the kernel command +line: +@example +ide1=noprobe ide2=noprobe ide3=noprobe ide4=noprobe ide5=noprobe +@end example + +@item +The example disk image is a modified version of the one made by Kevin +Lawton for the plex86 Project (@url{www.plex86.org}). + +@end enumerate + @node linux_compile @section Linux Kernel Compilation You can use any linux kernel with QEMU. However, if you want to use -@code{qemu-fast} to get maximum performances, you should make the -following changes to the Linux kernel (only 2.4.x and 2.5.x were -tested): +@code{qemu-fast} to get maximum performances, you must use a modified +guest kernel. If you are using a 2.6 guest kernel, you can use +directly the patch @file{linux-2.6-qemu-fast.patch} made by Rusty +Russel available in the QEMU source archive. Otherwise, you can make the +following changes @emph{by hand} to the Linux kernel: @enumerate @item @@ -694,10 +734,10 @@ by use an SMP kernel with QEMU, it only supports one CPU. @item -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 +If you are not using a 2.6 kernel as host kernel but if you use a target +2.6 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 +frequencies greater than 100 Hz on host Linux systems < 2.6. In @file{include/asm/param.h}, replace: @example @@ -762,322 +802,104 @@ Use @code{set architecture i8086} to dump 16 bit code. Then use @code{x/10i $cs*16+*eip} to dump the code at the PC position. @end enumerate -@chapter QEMU Internals - -@section QEMU compared to other emulators - -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). 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 dependent. QEMU uses some tricks -which make it relatively easily portable and simple while achieving good -performances. - -The basic idea is to split every x86 instruction into fewer simpler -instructions. Each simple instruction is implemented by a piece of C -code (see @file{op-i386.c}). Then a compile time tool (@file{dyngen}) -takes the corresponding object file (@file{op-i386.o}) to generate a -dynamic code generator which concatenates the simple instructions to -build a function (see @file{op-i386.h:dyngen_code()}). - -In essence, the process is similar to [1], but more work is done at -compile time. - -A key idea to get optimal performances is that constant parameters can -be passed to the simple operations. For that purpose, dummy ELF -relocations are generated with gcc for each constant parameter. Then, -the tool (@file{dyngen}) can locate the relocations and generate the -appriopriate C code to resolve them when building the dynamic code. - -That way, QEMU is no more difficult to port than a dynamic linker. - -To go even faster, GCC static register variables are used to keep the -state of the virtual CPU. - -@section Register allocation - -Since QEMU uses fixed simple instructions, no efficient register -allocation can be done. However, because RISC CPUs have a lot of -register, most of the virtual CPU state can be put in registers without -doing complicated register allocation. - -@section Condition code optimisations - -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 just stores one operand (called @code{CC_SRC}), the -result (called @code{CC_DST}) and the type of operation (called -@code{CC_OP}). - -@code{CC_OP} is almost never explicitely set in the generated code -because it is known at translation time. - -In order to increase performances, a backward pass is performed on the -generated simple instructions (see -@code{translate-i386.c:optimize_flags()}). When it can be proved that -the condition codes are not needed by the next instructions, no -condition codes are computed at all. - -@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 -considers that some state information of the virtual x86 CPU cannot -change in it. For example, if the SS, DS and ES segments have a zero -base, then the translator does not even generate an addition for the -segment base. - -[The FPU stack pointer register is not handled that way yet]. - -@section Translation cache - -A 2MByte cache holds the most recently used translations. For -simplicity, it is completely flushed when it is full. A translation unit -contains just a single basic block (a block of x86 instructions -terminated by a jump or by a virtual CPU state change which the -translator cannot deduce statically). - -@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. - -Although 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. 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 - -QEMU includes a generic system call translator for Linux. It means that -the parameters of the system calls can be converted to fix the -endianness and 32/64 bit issues. The IOCTLs are converted with a generic -type description system (see @file{ioctls.h} and @file{thunk.c}). +@chapter QEMU User space emulator invocation -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 Quick Start -@section Linux signals +In order to launch a Linux process, QEMU needs the process executable +itself and all the target (x86) dynamic libraries used by it. -Normal and real-time signals are queued along with their information -(@code{siginfo_t}) as it is done in the Linux kernel. Then an interrupt -request is done to the virtual CPU. When it is interrupted, one queued -signal is handled by generating a stack frame in the virtual CPU as the -Linux kernel does. The @code{sigreturn()} system call is emulated to return -from the virtual signal handler. +@itemize -Some signals (such as SIGALRM) directly come from the host. Other -signals are synthetized from the virtual CPU exceptions such as SIGFPE -when a division by zero is done (see @code{main.c:cpu_loop()}). +@item On x86, you can just try to launch any process by using the native +libraries: -The blocked signal mask is still handled by the host Linux kernel so -that most signal system calls can be redirected directly to the host -Linux kernel. Only the @code{sigaction()} and @code{sigreturn()} system -calls need to be fully emulated (see @file{signal.c}). +@example +qemu-i386 -L / /bin/ls +@end example -@section clone() system call and threads +@code{-L /} tells that the x86 dynamic linker must be searched with a +@file{/} prefix. -The Linux clone() system call is usually used to create a thread. QEMU -uses the host clone() system call so that real host threads are created -for each emulated thread. One virtual CPU instance is created for each -thread. +@item Since QEMU is also a linux process, you can launch qemu with qemu (NOTE: you can only do that if you compiled QEMU from the sources): -The virtual x86 CPU atomic operations are emulated with a global lock so -that their semantic is preserved. +@example +qemu-i386 -L / qemu-i386 -L / /bin/ls +@end example -Note that currently there are still some locking issues in QEMU. In -particular, the translated cache flush is not protected yet against -reentrancy. +@item On non x86 CPUs, you need first to download at least an x86 glibc +(@file{qemu-runtime-i386-XXX-.tar.gz} on the QEMU web page). Ensure that +@code{LD_LIBRARY_PATH} is not set: -@section Self-virtualization +@example +unset LD_LIBRARY_PATH +@end example -QEMU was conceived so that ultimately it can emulate itself. Although -it is not very useful, it is an important test to show the power of the -emulator. +Then you can launch the precompiled @file{ls} x86 executable: -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. +@example +qemu-i386 tests/i386/ls +@end example +You can look at @file{qemu-binfmt-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. -@section MMU emulation +@item The x86 version of QEMU is also included. You can try weird things such as: +@example +qemu-i386 /usr/local/qemu-i386/bin/qemu-i386 /usr/local/qemu-i386/bin/ls-i386 +@end example -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). +@end itemize -It is planned to add a slower but more precise MMU emulation -with a software MMU. +@section Wine launch -@section Bibliography +@itemize -@table @asis +@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: -@item [1] -@url{http://citeseer.nj.nec.com/piumarta98optimizing.html}, Optimizing -direct threaded code by selective inlining (1998) by Ian Piumarta, Fabio -Riccardi. +@example +qemu-i386 /usr/local/qemu-i386/bin/ls-i386 +@end example -@item [2] -@url{http://developer.kde.org/~sewardj/}, Valgrind, an open-source -memory debugger for x86-GNU/Linux, by Julian Seward. +@item Download the binary x86 Wine install +(@file{qemu-XXX-i386-wine.tar.gz} on the QEMU web page). -@item [3] -@url{http://bochs.sourceforge.net/}, the Bochs IA-32 Emulator Project, -by Kevin Lawton et al. +@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 [4] -@url{http://www.cs.rose-hulman.edu/~donaldlf/em86/index.html}, the EM86 -x86 emulator on Alpha-Linux. +@item Then you can try the example @file{putty.exe}: -@item [5] -@url{http://www.usenix.org/publications/library/proceedings/usenix-nt97/full_papers/chernoff/chernoff.pdf}, -DIGITAL FX!32: Running 32-Bit x86 Applications on Alpha NT, by Anton -Chernoff and Ray Hookway. +@example +qemu-i386 /usr/local/qemu-i386/wine/bin/wine /usr/local/qemu-i386/wine/c/Program\ Files/putty.exe +@end example -@item [6] -@url{http://www.willows.com/}, Windows API library emulation from -Willows Software. +@end itemize -@item [7] -@url{http://user-mode-linux.sourceforge.net/}, -The User-mode Linux Kernel. +@section Command line options -@item [8] -@url{http://www.plex86.org/}, -The new Plex86 project. +@example +usage: qemu-i386 [-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 -@chapter Regression Tests - -In the directory @file{tests/}, various interesting testing programs -are available. There are used for regression testing. - -@section @file{test-i386} - -This program executes most of the 16 bit and 32 bit x86 instructions and -generates a text output. It can be compared with the output obtained with -a real CPU or another emulator. The target @code{make test} runs this -program and a @code{diff} on the generated output. - -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. - -The Linux system call @code{vm86()} is used to test vm86 emulation. - -Various exceptions are raised to test most of the x86 user space -exception reporting. - -@section @file{linux-test} - -This program tests various Linux system calls. It is used to verify -that the system call parameters are correctly converted between target -and host CPUs. - -@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{sha1} +Debug options: -It is a simple benchmark. Care must be taken to interpret the results -because it mostly tests the ability of the virtual CPU to optimize the -@code{rol} x86 instruction and the condition code computations. +@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 diff --git a/qemu-tech.texi b/qemu-tech.texi new file mode 100644 index 0000000000..0185934756 --- /dev/null +++ b/qemu-tech.texi @@ -0,0 +1,506 @@ +\input texinfo @c -*- texinfo -*- + +@iftex +@settitle QEMU Internals +@titlepage +@sp 7 +@center @titlefont{QEMU Internals} +@sp 3 +@end titlepage +@end iftex + +@chapter Introduction + +@section Features + +QEMU is a FAST! processor emulator using a portable dynamic +translator. + +QEMU has two operating modes: + +@itemize @minus + +@item +Full system emulation. In this mode, QEMU emulates a full system +(usually a PC), including a processor and various peripherials. It can +be used to launch an different Operating System without rebooting the +PC or to debug system code. + +@item +User mode emulation (Linux host only). In this mode, QEMU can launch +Linux processes compiled for one CPU on another CPU. It can be used to +launch the Wine Windows API emulator (@url{http://www.winehq.org}) or +to ease cross-compilation and cross-debugging. + +@end itemize + +As QEMU requires no host kernel driver to run, it is very safe and +easy to use. + +QEMU generic features: + +@itemize + +@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 Precise exceptions support. + +@item The virtual CPU is a library (@code{libqemu}) which can be used +in other projects. + +@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 QEMU can either use a full software MMU for maximum portability or use the host system call mmap() to simulate the target MMU. +@end itemize + +@section x86 emulation + +QEMU x86 target features: + +@itemize + +@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. + +@end itemize + +Current QEMU limitations: + +@itemize + +@item No SSE/MMX support (yet). + +@item No x86-64 support. + +@item IPC syscalls are missing. + +@item The x86 segment limits and access rights are not tested at every +memory access (yet). Hopefully, very few OSes seem to rely on that for +normal use. + +@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. + +@end itemize + +@section ARM emulation + +@itemize + +@item Full ARM 7 user emulation. + +@item NWFPE FPU support included in user Linux emulation. + +@item Can run most ARM Linux binaries. + +@end itemize + +@section PowerPC emulation + +@itemize + +@item Full PowerPC 32 bit emulation, including priviledged instructions, +FPU and MMU. + +@item Can run most PowerPC Linux binaries. + +@end itemize + +@section SPARC emulation + +@itemize + +@item SPARC V8 user support, except FPU instructions. + +@item Can run some SPARC Linux binaries. + +@end itemize + +@chapter QEMU Internals + +@section QEMU compared to other emulators + +Like bochs [3], QEMU emulates an x86 CPU. But QEMU is much faster than +bochs as it uses dynamic compilation. Bochs is closely tied to x86 PC +emulation while QEMU can emulate several processors. + +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). 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. The price to pay is that QEMU is +slower. + +The new Plex86 [8] PC virtualizer is done in the same spirit as the +qemu-fast 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. + +The commercial PC Virtualizers (VMWare [9], VirtualPC [10], TwoOStwo +[11]) are faster than QEMU, but they all need specific, proprietary +and potentially unsafe host drivers. Moreover, they are unable to +provide cycle exact simulation as an emulator can. + +@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 dependent. QEMU uses some tricks +which make it relatively easily portable and simple while achieving good +performances. + +The basic idea is to split every x86 instruction into fewer simpler +instructions. Each simple instruction is implemented by a piece of C +code (see @file{target-i386/op.c}). Then a compile time tool +(@file{dyngen}) takes the corresponding object file (@file{op.o}) +to generate a dynamic code generator which concatenates the simple +instructions to build a function (see @file{op.h:dyngen_code()}). + +In essence, the process is similar to [1], but more work is done at +compile time. + +A key idea to get optimal performances is that constant parameters can +be passed to the simple operations. For that purpose, dummy ELF +relocations are generated with gcc for each constant parameter. Then, +the tool (@file{dyngen}) can locate the relocations and generate the +appriopriate C code to resolve them when building the dynamic code. + +That way, QEMU is no more difficult to port than a dynamic linker. + +To go even faster, GCC static register variables are used to keep the +state of the virtual CPU. + +@section Register allocation + +Since QEMU uses fixed simple instructions, no efficient register +allocation can be done. However, because RISC CPUs have a lot of +register, most of the virtual CPU state can be put in registers without +doing complicated register allocation. + +@section Condition code optimisations + +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 just stores one operand (called @code{CC_SRC}), the +result (called @code{CC_DST}) and the type of operation (called +@code{CC_OP}). + +@code{CC_OP} is almost never explicitely set in the generated code +because it is known at translation time. + +In order to increase performances, a backward pass is performed on the +generated simple instructions (see +@code{target-i386/translate.c:optimize_flags()}). When it can be proved that +the condition codes are not needed by the next instructions, no +condition codes are computed at all. + +@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 +considers that some state information of the virtual x86 CPU cannot +change in it. For example, if the SS, DS and ES segments have a zero +base, then the translator does not even generate an addition for the +segment base. + +[The FPU stack pointer register is not handled that way yet]. + +@section Translation cache + +A 2MByte cache holds the most recently used translations. For +simplicity, it is completely flushed when it is full. A translation unit +contains just a single basic block (a block of x86 instructions +terminated by a jump or by a virtual CPU state change which the +translator cannot deduce statically). + +@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 host +architectures (such as x86 or 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. + +Although 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()}. + +When using a software MMU, the code invalidation is more efficient: if +a given code page is invalidated too often because of write accesses, +then a bitmap representing all the code inside the page is +built. Every store into that page checks the bitmap to see if the code +really needs to be invalidated. It avoids invalidating the code when +only data is modified in the page. + +@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. 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 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). + +In order to be able to launch any OS, QEMU also supports a soft +MMU. In that mode, the MMU virtual to physical address translation is +done at every memory access. QEMU uses an address translation cache to +speed up the translation. + +In order to avoid flushing the translated code each time the MMU +mappings change, QEMU uses a physically indexed translation cache. It +means that each basic block is indexed with its physical address. + +When MMU mappings change, only the chaining of the basic blocks is +reset (i.e. a basic block can no longer jump directly to another one). + +@section Hardware interrupts + +In order to be faster, QEMU does not check at every basic block if an +hardware interrupt is pending. Instead, the user must asynchrously +call a specific function to tell that an interrupt is pending. This +function resets the chaining of the currently executing basic +block. It ensures that the execution will return soon in the main loop +of the CPU emulator. Then the main loop can test if the interrupt is +pending and handle it. + +@section User emulation specific details + +@subsection Linux system call translation + +QEMU includes a generic system call translator for Linux. It means that +the parameters of the system calls can be converted to fix the +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. + +@subsection Linux signals + +Normal and real-time signals are queued along with their information +(@code{siginfo_t}) as it is done in the Linux kernel. Then an interrupt +request is done to the virtual CPU. When it is interrupted, one queued +signal is handled by generating a stack frame in the virtual CPU as the +Linux kernel does. The @code{sigreturn()} system call is emulated to return +from the virtual signal handler. + +Some signals (such as SIGALRM) directly come from the host. Other +signals are synthetized from the virtual CPU exceptions such as SIGFPE +when a division by zero is done (see @code{main.c:cpu_loop()}). + +The blocked signal mask is still handled by the host Linux kernel so +that most signal system calls can be redirected directly to the host +Linux kernel. Only the @code{sigaction()} and @code{sigreturn()} system +calls need to be fully emulated (see @file{signal.c}). + +@subsection clone() system call and threads + +The Linux clone() system call is usually used to create a thread. QEMU +uses the host clone() system call so that real host threads are created +for each emulated thread. One virtual CPU instance is created for each +thread. + +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. + +@subsection Self-virtualization + +QEMU was conceived so that ultimately it can emulate itself. Although +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 Bibliography + +@table @asis + +@item [1] +@url{http://citeseer.nj.nec.com/piumarta98optimizing.html}, Optimizing +direct threaded code by selective inlining (1998) by Ian Piumarta, Fabio +Riccardi. + +@item [2] +@url{http://developer.kde.org/~sewardj/}, Valgrind, an open-source +memory debugger for x86-GNU/Linux, by Julian Seward. + +@item [3] +@url{http://bochs.sourceforge.net/}, the Bochs IA-32 Emulator Project, +by Kevin Lawton et al. + +@item [4] +@url{http://www.cs.rose-hulman.edu/~donaldlf/em86/index.html}, the EM86 +x86 emulator on Alpha-Linux. + +@item [5] +@url{http://www.usenix.org/publications/library/proceedings/usenix-nt97/full_papers/chernoff/chernoff.pdf}, +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. + +@item [9] +@url{http://www.vmware.com/}, +The VMWare PC virtualizer. + +@item [10] +@url{http://www.microsoft.com/windowsxp/virtualpc/}, +The VirtualPC PC virtualizer. + +@item [11] +@url{http://www.twoostwo.org/}, +The TwoOStwo PC virtualizer. + +@end table + +@chapter Regression Tests + +In the directory @file{tests/}, various interesting testing programs +are available. There are used for regression testing. + +@section @file{test-i386} + +This program executes most of the 16 bit and 32 bit x86 instructions and +generates a text output. It can be compared with the output obtained with +a real CPU or another emulator. The target @code{make test} runs this +program and a @code{diff} on the generated output. + +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. + +The Linux system call @code{vm86()} is used to test vm86 emulation. + +Various exceptions are raised to test most of the x86 user space +exception reporting. + +@section @file{linux-test} + +This program tests various Linux system calls. It is used to verify +that the system call parameters are correctly converted between target +and host CPUs. + +@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{sha1} + +It is a simple benchmark. Care must be taken to interpret the results +because it mostly tests the ability of the virtual CPU to optimize the +@code{rol} x86 instruction and the condition code computations. + |