Diff for /qemu/qemu-tech.texi between versions 1.1.1.3 and 1.1.1.4

version 1.1.1.3, 2018/04/24 16:47:30 version 1.1.1.4, 2018/04/24 16:50:50
Line 33 Line 33
   
 @menu  @menu
 * intro_features::        Features  * intro_features::        Features
 * intro_x86_emulation::   x86 emulation  * intro_x86_emulation::   x86 and x86-64 emulation
 * intro_arm_emulation::   ARM emulation  * intro_arm_emulation::   ARM emulation
 * intro_mips_emulation::  MIPS emulation  * intro_mips_emulation::  MIPS emulation
 * intro_ppc_emulation::   PowerPC emulation  * intro_ppc_emulation::   PowerPC emulation
 * intro_sparc_emulation:: SPARC emulation  * intro_sparc_emulation:: Sparc32 and Sparc64 emulation
   * intro_other_emulation:: Other CPU emulation
 @end menu  @end menu
   
 @node intro_features  @node intro_features
Line 51  QEMU has two operating modes: Line 52  QEMU has two operating modes:
 @itemize @minus  @itemize @minus
   
 @item  @item
 Full system emulation. In this mode, QEMU emulates a full system  Full system emulation. In this mode (full platform virtualization),
 (usually a PC), including a processor and various peripherals. It can  QEMU emulates a full system (usually a PC), including a processor and
 be used to launch an different Operating System without rebooting the  various peripherals. It can be used to launch several different
 PC or to debug system code.  Operating Systems at once without rebooting the host machine or to
   debug system code.
   
 @item  @item
 User mode emulation (Linux host only). In this mode, QEMU can launch  User mode emulation. In this mode (application level virtualization),
 Linux processes compiled for one CPU on another CPU. It can be used to  QEMU can launch processes compiled for one CPU on another CPU, however
 launch the Wine Windows API emulator (@url{http://www.winehq.org}) or  the Operating Systems must match. This can be used for example to ease
 to ease cross-compilation and cross-debugging.  cross-compilation and cross-debugging.
   
 @end itemize  @end itemize
   
 As QEMU requires no host kernel driver to run, it is very safe and  As QEMU requires no host kernel driver to run, it is very safe and
Line 75  QEMU generic features: Line 76  QEMU generic features:
   
 @item Using dynamic translation to native code for reasonable speed.  @item Using dynamic translation to native code for reasonable speed.
   
 @item Working on x86 and PowerPC hosts. Being tested on ARM, Sparc32, Alpha and S390.  @item
   Working on x86, x86_64 and PowerPC32/64 hosts. Being tested on ARM,
   HPPA, Sparc32 and Sparc64. Previous versions had some support for
   Alpha and S390 hosts, but TCG (see below) doesn't support those yet.
   
 @item Self-modifying code support.  @item Self-modifying code support.
   
Line 85  QEMU generic features: Line 89  QEMU generic features:
 in other projects (look at @file{qemu/tests/qruncom.c} to have an  in other projects (look at @file{qemu/tests/qruncom.c} to have an
 example of user mode @code{libqemu} usage).  example of user mode @code{libqemu} usage).
   
   @item
   Floating point library supporting both full software emulation and
   native host FPU instructions.
   
 @end itemize  @end itemize
   
 QEMU user mode emulation features:  QEMU user mode emulation features:
Line 96  QEMU user mode emulation features: Line 104  QEMU user mode emulation features:
 @item Accurate signal handling by remapping host signals to target signals.  @item Accurate signal handling by remapping host signals to target signals.
 @end itemize  @end itemize
   
   Linux user emulator (Linux host only) can be used to launch the Wine
   Windows API emulator (@url{http://www.winehq.org}). A Darwin user
   emulator (Darwin hosts only) exists and a BSD user emulator for BSD
   hosts is under development. It would also be possible to develop a
   similar user emulator for Solaris.
   
 QEMU full system emulation features:  QEMU full system emulation features:
 @itemize  @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.  @item
   QEMU uses a full software MMU for maximum portability.
   
   @item
   QEMU can optionally use an in-kernel accelerator, like kqemu and
   kvm. The accelerators execute some of the guest code natively, while
   continuing to emulate the rest of the machine.
   
   @item
   Various hardware devices can be emulated and in some cases, host
   devices (e.g. serial and parallel ports, USB, drives) can be used
   transparently by the guest Operating System. Host device passthrough
   can be used for talking to external physical peripherals (e.g. a
   webcam, modem or tape drive).
   
   @item
   Symmetric multiprocessing (SMP) even on a host with a single CPU. On a
   SMP host system, QEMU can use only one CPU fully due to difficulty in
   implementing atomic memory accesses efficiently.
   
 @end itemize  @end itemize
   
 @node intro_x86_emulation  @node intro_x86_emulation
 @section x86 emulation  @section x86 and x86-64 emulation
   
 QEMU x86 target features:  QEMU x86 target features:
   
 @itemize  @itemize
   
 @item The virtual x86 CPU supports 16 bit and 32 bit addressing with segmentation.  @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.  LDT/GDT and IDT are emulated. VM86 mode is also supported to run
   DOSEMU. There is some support for MMX/3DNow!, SSE, SSE2, SSE3, SSSE3,
   and SSE4 as well as x86-64 SVM.
   
 @item Support of host page sizes bigger than 4KB in user mode emulation.  @item Support of host page sizes bigger than 4KB in user mode emulation.
   
Line 124  Current QEMU limitations: Line 159  Current QEMU limitations:
   
 @itemize  @itemize
   
 @item No SSE/MMX support (yet).  @item Limited x86-64 support.
   
 @item No x86-64 support.  
   
 @item IPC syscalls are missing.  @item IPC syscalls are missing.
   
Line 134  Current QEMU limitations: Line 167  Current QEMU limitations:
 memory access (yet). Hopefully, very few OSes seem to rely on that for  memory access (yet). Hopefully, very few OSes seem to rely on that for
 normal use.  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  @end itemize
   
 @node intro_arm_emulation  @node intro_arm_emulation
Line 193  FPU and MMU. Line 222  FPU and MMU.
 @end itemize  @end itemize
   
 @node intro_sparc_emulation  @node intro_sparc_emulation
 @section SPARC emulation  @section Sparc32 and Sparc64 emulation
   
 @itemize  @itemize
   
Line 216  Current QEMU limitations: Line 245  Current QEMU limitations:
   
 @item Atomic instructions are not correctly implemented.  @item Atomic instructions are not correctly implemented.
   
 @item Sparc64 emulators are not usable for anything yet.  @item There are still some problems with Sparc64 emulators.
   
 @end itemize  @end itemize
   
   @node intro_other_emulation
   @section Other CPU emulation
   
   In addition to the above, QEMU supports emulation of other CPUs with
   varying levels of success. These are:
   
   @itemize
   
   @item
   Alpha
   @item
   CRIS
   @item
   M68k
   @item
   SH4
   @end itemize
   
 @node QEMU Internals  @node QEMU Internals
 @chapter QEMU Internals  @chapter QEMU Internals
   
 @menu  @menu
 * QEMU compared to other emulators::  * QEMU compared to other emulators::
 * Portable dynamic translation::  * Portable dynamic translation::
 * Register allocation::  
 * Condition code optimisations::  * Condition code optimisations::
 * CPU state optimisations::  * CPU state optimisations::
 * Translation cache::  * Translation cache::
Line 234  Current QEMU limitations: Line 280  Current QEMU limitations:
 * Self-modifying code and translated code invalidation::  * Self-modifying code and translated code invalidation::
 * Exception support::  * Exception support::
 * MMU emulation::  * MMU emulation::
   * Device emulation::
 * Hardware interrupts::  * Hardware interrupts::
 * User emulation specific details::  * User emulation specific details::
 * Bibliography::  * Bibliography::
Line 273  patches. However, user mode Linux requir Line 320  patches. However, user mode Linux requir
 QEMU accepts unpatched Linux kernels. The price to pay is that QEMU is  QEMU accepts unpatched Linux kernels. The price to pay is that QEMU is
 slower.  slower.
   
 The new Plex86 [8] PC virtualizer is done in the same spirit as the  The Plex86 [8] PC virtualizer is done in the same spirit as the now
 qemu-fast system emulator. It requires a patched Linux kernel to work  obsolete qemu-fast system emulator. It requires a patched Linux kernel
 (you cannot launch the same kernel on your PC), but the patches are  to work (you cannot launch the same kernel on your PC), but the
 really small. As it is a PC virtualizer (no emulation is done except  patches are really small. As it is a PC virtualizer (no emulation is
 for some priveledged instructions), it has the potential of being  done except for some privileged instructions), it has the potential of
 faster than QEMU. The downside is that a complicated (and potentially  being faster than QEMU. The downside is that a complicated (and
 unsafe) host kernel patch is needed.  potentially unsafe) host kernel patch is needed.
   
 The commercial PC Virtualizers (VMWare [9], VirtualPC [10], TwoOStwo  The commercial PC Virtualizers (VMWare [9], VirtualPC [10], TwoOStwo
 [11]) are faster than QEMU, but they all need specific, proprietary  [11]) are faster than QEMU, but they all need specific, proprietary
 and potentially unsafe host drivers. Moreover, they are unable to  and potentially unsafe host drivers. Moreover, they are unable to
 provide cycle exact simulation as an emulator can.  provide cycle exact simulation as an emulator can.
   
   VirtualBox [12], Xen [13] and KVM [14] are based on QEMU. QEMU-SystemC
   [15] uses QEMU to simulate a system where some hardware devices are
   developed in SystemC.
   
 @node Portable dynamic translation  @node Portable dynamic translation
 @section Portable dynamic translation  @section Portable dynamic translation
   
Line 295  are very complicated and highly CPU depe Line 346  are very complicated and highly CPU depe
 which make it relatively easily portable and simple while achieving good  which make it relatively easily portable and simple while achieving good
 performances.  performances.
   
 The basic idea is to split every x86 instruction into fewer simpler  After the release of version 0.9.1, QEMU switched to a new method of
 instructions. Each simple instruction is implemented by a piece of C  generating code, Tiny Code Generator or TCG. TCG relaxes the
 code (see @file{target-i386/op.c}). Then a compile time tool  dependency on the exact version of the compiler used. The basic idea
 (@file{dyngen}) takes the corresponding object file (@file{op.o})  is to split every target instruction into a couple of RISC-like TCG
 to generate a dynamic code generator which concatenates the simple  ops (see @code{target-i386/translate.c}). Some optimizations can be
 instructions to build a function (see @file{op.h:dyngen_code()}).  performed at this stage, including liveness analysis and trivial
   constant expression evaluation. TCG ops are then implemented in the
 In essence, the process is similar to [1], but more work is done at  host CPU back end, also known as TCG target (see
 compile time.  @code{tcg/i386/tcg-target.c}). For more information, please take a
   look at @code{tcg/README}.
 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.  
   
 @node Register allocation  
 @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.  
   
 @node Condition code optimisations  @node Condition code optimisations
 @section Condition code optimisations  @section Condition code optimisations
   
 Good CPU condition codes emulation (@code{EFLAGS} register on x86) is a  Lazy evaluation of CPU condition codes (@code{EFLAGS} register on x86)
 critical point to get good performances. QEMU uses lazy condition code  is important for CPUs where every instruction sets the condition
 evaluation: instead of computing the condition codes after each x86  codes. It tends to be less important on conventional RISC systems
 instruction, it just stores one operand (called @code{CC_SRC}), the  where condition codes are only updated when explicitly requested.
 result (called @code{CC_DST}) and the type of operation (called  
 @code{CC_OP}).  Instead of computing the condition codes after each x86 instruction,
   QEMU just stores one operand (called @code{CC_SRC}), the result
   (called @code{CC_DST}) and the type of operation (called
   @code{CC_OP}). When the condition codes are needed, the condition
   codes can be calculated using this information. In addition, an
   optimized calculation can be performed for some instruction types like
   conditional branches.
   
 @code{CC_OP} is almost never explicitely set in the generated code  @code{CC_OP} is almost never explicitly set in the generated code
 because it is known at translation time.  because it is known at translation time.
   
 In order to increase performances, a backward pass is performed on the  The lazy condition code evaluation is used on x86, m68k and cris. ARM
 generated simple instructions (see  uses a simplified variant for the N and Z flags.
 @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.  
   
 @node CPU state optimisations  @node CPU state optimisations
 @section CPU state optimisations  @section CPU state optimisations
   
 The x86 CPU has many internal states which change the way it evaluates  The target CPUs have many internal states which change the way it
 instructions. In order to achieve a good speed, the translation phase  evaluates instructions. In order to achieve a good speed, the
 considers that some state information of the virtual x86 CPU cannot  translation phase considers that some state information of the virtual
 change in it. For example, if the SS, DS and ES segments have a zero  CPU cannot change in it. The state is recorded in the Translation
 base, then the translator does not even generate an addition for the  Block (TB). If the state changes (e.g. privilege level), a new TB will
 segment base.  be generated and the previous TB won't be used anymore until the state
   matches the state recorded in the previous TB. 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].  [The FPU stack pointer register is not handled that way yet].
   
Line 388  instruction cache invalidation is signal Line 427  instruction cache invalidation is signal
 is modified.  is modified.
   
 When translated code is generated for a basic block, the corresponding  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  host page is write protected if it is not already read-only. Then, if
 system call @code{mprotect()}). Then, if a write access is done to the  a write access is done to the page, Linux raises a SEGV signal. QEMU
 page, Linux raises a SEGV signal. QEMU then invalidates all the  then invalidates all the translated code in the page and enables write
 translated code in the page and enables write accesses to the page.  accesses to the page.
   
 Correct translated code invalidation is done efficiently by maintaining  Correct translated code invalidation is done efficiently by maintaining
 a linked list of every translated block contained in a given page. Other  a linked list of every translated block contained in a given page. Other
 linked lists are also maintained to undo direct block chaining.  linked lists are also maintained to undo direct block chaining.
   
 Although the overhead of doing @code{mprotect()} calls is important,  On RISC targets, correctly written software uses memory barriers and
 most MSDOS programs can be emulated at reasonnable speed with QEMU and  cache flushes, so some of the protection above would not be
 DOSEMU.  necessary. However, QEMU still requires that the generated code always
   matches the target instructions in memory in order to handle
 Note that QEMU also invalidates pages of translated code when it detects  exceptions correctly.
 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.  
   
 @node Exception support  @node Exception support
 @section Exception support  @section Exception support
Line 418  longjmp() is used when an exception such Line 449  longjmp() is used when an exception such
 encountered.  encountered.
   
 The host SIGSEGV and SIGBUS signal handlers are used to get invalid  The host SIGSEGV and SIGBUS signal handlers are used to get invalid
 memory accesses. The exact CPU state can be retrieved because all the  memory accesses. The simulated program counter is found by
 x86 registers are stored in fixed host registers. The simulated program  retranslating the corresponding basic block and by looking where the
 counter is found by retranslating the corresponding basic block and by  host program counter was at the exception point.
 looking where the host program counter was at the exception point.  
   
 The virtual CPU cannot retrieve the exact @code{EFLAGS} register because  The virtual CPU cannot retrieve the exact @code{EFLAGS} register because
 in some cases it is not computed because of condition code  in some cases it is not computed because of condition code
Line 431  still be restarted in any cases. Line 461  still be restarted in any cases.
 @node MMU emulation  @node MMU emulation
 @section MMU emulation  @section MMU emulation
   
 For system emulation, QEMU uses the mmap() system call to emulate the  For system emulation QEMU supports a soft MMU. In that mode, the MMU
 target CPU MMU. It works as long the emulated OS does not use an area  virtual to physical address translation is done at every memory
 reserved by the host OS (such as the area above 0xc0000000 on x86  access. QEMU uses an address translation cache to speed up the
 Linux).  translation.
   
 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  In order to avoid flushing the translated code each time the MMU
 mappings change, QEMU uses a physically indexed translation cache. It  mappings change, QEMU uses a physically indexed translation cache. It
Line 448  means that each basic block is indexed w Line 473  means that each basic block is indexed w
 When MMU mappings change, only the chaining of the basic blocks is  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).  reset (i.e. a basic block can no longer jump directly to another one).
   
   @node Device emulation
   @section Device emulation
   
   Systems emulated by QEMU are organized by boards. At initialization
   phase, each board instantiates a number of CPUs, devices, RAM and
   ROM. Each device in turn can assign I/O ports or memory areas (for
   MMIO) to its handlers. When the emulation starts, an access to the
   ports or MMIO memory areas assigned to the device causes the
   corresponding handler to be called.
   
   RAM and ROM are handled more optimally, only the offset to the host
   memory needs to be added to the guest address.
   
   The video RAM of VGA and other display cards is special: it can be
   read or written directly like RAM, but write accesses cause the memory
   to be marked with VGA_DIRTY flag as well.
   
   QEMU supports some device classes like serial and parallel ports, USB,
   drives and network devices, by providing APIs for easier connection to
   the generic, higher level implementations. The API hides the
   implementation details from the devices, like native device use or
   advanced block device formats like QCOW.
   
   Usually the devices implement a reset method and register support for
   saving and loading of the device state. The devices can also use
   timers, especially together with the use of bottom halves (BHs).
   
 @node Hardware interrupts  @node Hardware interrupts
 @section Hardware interrupts  @section Hardware interrupts
   
Line 513  it is not very useful, it is an importan Line 565  it is not very useful, it is an importan
 emulator.  emulator.
   
 Achieving self-virtualization is not easy because there may be address  Achieving self-virtualization is not easy because there may be address
 space conflicts. QEMU solves this problem by being an executable ELF  space conflicts. QEMU user emulators solve this problem by being an
 shared object as the ld-linux.so ELF interpreter. That way, it can be  executable ELF shared object as the ld-linux.so ELF interpreter. That
 relocated at load time.  way, it can be relocated at load time.
   
 @node Bibliography  @node Bibliography
 @section Bibliography  @section Bibliography
Line 568  The VirtualPC PC virtualizer. Line 620  The VirtualPC PC virtualizer.
 @url{http://www.twoostwo.org/},  @url{http://www.twoostwo.org/},
 The TwoOStwo PC virtualizer.  The TwoOStwo PC virtualizer.
   
   @item [12]
   @url{http://virtualbox.org/},
   The VirtualBox PC virtualizer.
   
   @item [13]
   @url{http://www.xen.org/},
   The Xen hypervisor.
   
   @item [14]
   @url{http://kvm.qumranet.com/kvmwiki/Front_Page},
   Kernel Based Virtual Machine (KVM).
   
   @item [15]
   @url{http://www.greensocs.com/projects/QEMUSystemC},
   QEMU-SystemC, a hardware co-simulator.
   
 @end table  @end table
   
 @node Regression Tests  @node Regression Tests

Removed from v.1.1.1.3  
changed lines
  Added in v.1.1.1.4


unix.superglobalmegacorp.com