\input texinfo @c -*- texinfo -*-
@c %**start of header
@setfilename qemu-tech.info
+
+@documentlanguage en
+@documentencoding UTF-8
+
@settitle QEMU Internals
@exampleindent 0
@paragraphindent 0
@c %**end of header
+@ifinfo
+@direntry
+* QEMU Internals: (qemu-tech). The QEMU Emulator Internals.
+@end direntry
+@end ifinfo
+
@iftex
@titlepage
@sp 7
@chapter Introduction
@menu
-* intro_features:: Features
-* intro_x86_emulation:: x86 and x86-64 emulation
-* intro_arm_emulation:: ARM emulation
-* intro_mips_emulation:: MIPS emulation
-* intro_ppc_emulation:: PowerPC emulation
-* intro_sparc_emulation:: Sparc32 and Sparc64 emulation
-* intro_other_emulation:: Other CPU emulation
+* intro_features:: Features
+* intro_x86_emulation:: x86 and x86-64 emulation
+* intro_arm_emulation:: ARM emulation
+* intro_mips_emulation:: MIPS emulation
+* intro_ppc_emulation:: PowerPC emulation
+* intro_sparc_emulation:: Sparc32 and Sparc64 emulation
+* intro_xtensa_emulation:: Xtensa emulation
+* intro_other_emulation:: Other CPU emulation
@end menu
@node intro_features
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
+QEMU can optionally use an in-kernel accelerator, like kvm. The accelerators
+execute some of the guest code natively, while
continuing to emulate the rest of the machine.
@item
@end itemize
+@node intro_xtensa_emulation
+@section Xtensa emulation
+
+@itemize
+
+@item Core Xtensa ISA emulation, including most options: code density,
+loop, extended L32R, 16- and 32-bit multiplication, 32-bit division,
+MAC16, miscellaneous operations, boolean, multiprocessor synchronization,
+conditional store, exceptions, relocatable vectors, unaligned exception,
+interrupts (including high priority and timer), hardware alignment,
+region protection, region translation, MMU, windowed registers, thread
+pointer, processor ID.
+
+@item Not implemented options: FP coprocessor, coprocessor context,
+data/instruction cache (including cache prefetch and locking), XLMI,
+processor interface, debug. Also options not covered by the core ISA
+(e.g. FLIX, wide branches) are not implemented.
+
+@item Can run most Xtensa Linux binaries.
+
+@item New core configuration that requires no additional instructions
+may be created from overlay with minimal amount of hand-written code.
+
+@end itemize
+
@node intro_other_emulation
@section Other CPU emulation
Lazy evaluation of CPU condition codes (@code{EFLAGS} register on x86)
is important for CPUs where every instruction sets the condition
codes. It tends to be less important on conventional RISC systems
-where condition codes are only updated when explicitly requested.
+where condition codes are only updated when explicitly requested. On
+Sparc64, costly update of both 32 and 64 bit condition codes can be
+avoided with lazy evaluation.
Instead of computing the condition codes after each x86 instruction,
QEMU just stores one operand (called @code{CC_SRC}), the result
@code{CC_OP} is almost never explicitly set in the generated code
because it is known at translation time.
-The lazy condition code evaluation is used on x86, m68k and cris. ARM
-uses a simplified variant for the N and Z flags.
+The lazy condition code evaluation is used on x86, m68k, cris and
+Sparc. ARM uses a simplified variant for the N and Z flags.
@node CPU state optimisations
@section CPU state optimisations
@node Translation cache
@section Translation cache
-A 16 MByte cache holds the most recently used translations. For
+A 32 MByte 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
@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
+hardware interrupt is pending. Instead, the user must asynchronously
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
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
+signals are synthesized 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
projects / qemu.git / blobdiff