auto import from //depot/cupcake/@136594

1 files changed, 91 insertions, 0 deletions

diff --git a/docs/CPU-EMULATION.TXT b/docs/CPU-EMULATION.TXT
new file mode 100644
index 0000000..303d6c0
--- /dev/null
+++ b/docs/CPU-EMULATION.TXT
@@ -0,0 +1,91 @@
+HOW THE QEMU EXECUTION ENGINE WORKS:
+====================================
+
+Translating ARM to x86 machine code:
+------------------------------------
+
+QEMU starts by isolating code "fragments" from the emulated machine code.
+Each "fragment" corresponds to a seris of ARM instructions ending with a
+branch (e.g. jumps, conditional branches, returns).
+
+Each fragment is translated into a "translated block" (a.k.a. TB) of host
+machine code (e.g. x86). All TBs are put in a cache and each time the
+instruction pointer changes (i.e. at the end of TB execution), a hash
+table lookup is performed to find the next TB to execute.
+
+If none exists, a new one is generated. As a special exception, it is
+sometimes possible to 'link' the end of a given TB to the start of
+another one by tacking an explicit jump instruction.
+
+Note that due to differences in translations of memory-related operations
+(described below in "MMU emulation"), there are actually two TB caches per
+emulated CPU: one for translated kernel code, and one for translated
+user-space code.
+
+When a cache fills up, it is simply totally emptied and translation starts
+again.
+
+CPU state is kept in a single global structure which the generated code
+can access directly (with direct memory addressing).
+
+the file target-arm/translate.c is in charge of translating the ARM or
+Thumb instructions starting at the current instruction pointer position
+into a TB. This is done by decomposing each instruction into a series of
+micro-operations supported by the TCG code generator.
+
+TCG stands for "Tiny Code Generator" and is specific to QEMU. It supports
+several host machine code backends. See source files under tcg/ for details.
+
+
+MMU Emulation:
+--------------
+
+The ARM Memory Management Unit is emulated in software, since it is so
+different from the one on the host. Essentially, a single ARM memory load/store
+instruction is translated into a series of host machine instructions that will
+translate virtual addresses into physical ones by performing the following:
+
+- first lookup in a global 256-entries cache for the current page and see if
+  a corresponding value is already stored there. If this is the case, use it
+  directly.
+
+- otherwise, call a special helper function that will implement the full
+  translation according to the emulated system's state, and modify the
+  cache accordingly.
+
+The page cache is called the "TLB" in the QEMU sources.
+
+Note that there are actually two TLBs: one is used for host machine
+instructions that correspond to kernel code, and the other for instructions
+translated from user-level code.
+
+This means that a memory load in the kernel will not be translated into the
+same instructions than the same load in user space.
+
+Each TLB is also implemented as a global per-CPU hash-table.
+The user-level TLB is flushed on each process context switch. 
+
+When initializing the MMU emulation, one can define several zones of the
+address space, with different access rights / type. This is how memory-mapped
+i/o is implemented: the virtual->physical conversion helper function detects
+that you're trying to read/write from an i/o memory region, and will then call
+a callback function associated to it.
+
+
+Hardware Emulation:
+-------------------
+
+Most hardware emulation code initializes by registering its own region of
+i/o memory, as well as providing read/write callbacks for it. Then actions 
+will be based on which offset of the i/o memory is read from/written to and
+eventually with which value.
+
+You can have a look at hw/goldfish_tty.c that implements an emulated serial
+port for the Goldfish platform.
+
+"Goldfish" is simply the name of the virtual Linux platform used to build
+the Android-emulator-specific kernel image. The corresponding sources are
+located in the origin/android-goldfish-2.6.27 branch of
+git://android.git.kernel.org/kernel/common.git. You can have a look at
+arch/arm/mach-goldfish/ for the corresponding kernel driver sources.
+