[<<][arm][>>][..]
Fri Dec 13 10:39:06 EST 2013

Qemu overview

High-level and mostly wrong overview of qemu:

- Asm code gets translated to TCG code, then compiled to native code
  or interpreted.

- Memory accesses are either based on the RAM/ROM objects, or sysbus objects

- sysbus objects have behavior associated to read/write.  they also
  interact with interrupts.

- not clear how exactly control flow works for interrupts

From [1]:

  2.11 Hardware interrupts

  In order to be faster, QEMU does not check at every basic block if a
  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 of the CPU emulator. Then the main loop can test if the
  interrupt is pending and handle it.

- guest code is called synchronously[2]:

  ... what matters is that both TCG and KVM allow us to jump into
  guest code and execute it.  Jumping into guest code takes away our
  control of execution and gives control to the guest.  While a thread
  is running guest code it cannot simultaneously be in the event loop
  because the guest has (safe) control of the CPU. Typically the
  amount of time spent in guest code is limited because reads and
  writes to emulated device registers and other exceptions cause us to
  leave the guest and give control back to QEMU. In extreme cases a
  guest can spend an unbounded amount of time without giving up
  control and this would make QEMU unresponsive.  In order to solve
  the problem of guest code hogging QEMU's thread of control signals
  are used to break out of the guest.

[1] http://ellcc.org/ellcc/share/doc/qemu/qemu-tech.html#Hardware-interrupts
[2] http://blog.vmsplice.net/2011/03/qemu-internals-overall-architecture-and.html



[Reply][About]
[<<][arm][>>][..]