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 series 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-emulated-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/android/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.29 branch of
https://android.googlesource.com/kernel/goldfish.git. You can have a look at
arch/arm/mach-goldfish/ for the corresponding kernel driver sources.