Greetings,
I have been working with QEmu for a few months now at Wind River. I
am sure many of you already know Jason Wessel and Alex deVries who
championed QEmu as a tool for our Linux product. It is my goal to
demonstrate the power of QEmu for embedded software development
(excuse me, DSO - Device Software Optimization). I have identified
several areas in which some work needs to be done to make QEmu more
appropriate for embedded development. I am interested in comments or
pointers to existing work for several areas (I have also done work in
many of these areas already). I have been working mainly with
PowerPC targets and X86 Linux as a host.
System Clock - Currently it appears to me that QEmu attempt to sync
the "system clock" with realtime resulting in a different number of
emulated "clock" cycles per clock interrupt. In the embedded
environment we are typically much more interested in a deterministic
result from the clock. For the PowerPC I have implemented an
alternate implementation of the TB and Decrementer that increments
the time base based on the number of emulated instructions that have
been processed. It is not perfect, but at least now the timer
interrupt is triggered when the decrementer goes negative. Have
others worked on this problem?
QEmu Target Configuration - I would like to define a configuration
file syntax (I cannot help but think back to my BSDi days and the BSD/
OS kernel configuration file) that would define the hardware from the
outside. Device drivers would either need to be already linked in,
or be able to be dynamically loaded. I would expect that things such
as the memory map, type of interrupt controller, the various devices
along with their io port and memory addresses and interrupts would be
defined here. Again, this would not replace the current system, but
would essentially be a new init module. I do not want to see any
working configurations break.
Paravirtualization - I have written a "device driver" for QEmu that
allows the guest system to essentially make function calls right into
the host (dealing with data representation, etc). A prime example
for use of this is OpenGL. OpenGL is pretty much done in hardware
these days, and most embedded devices do not use X11 as a graphics
system. By providing an OpenGL library on the target OS that
basically calls straight into the hosts OpenGL library it should be
possible to greatly increase the performance of the target without
having to try and export the real graphics hardware into QEmu. Along
with this I have done the necessary work to allow QEmu to use dlopen
() to load in arbitrary shim layers to libraries.
There are other areas as well, such as deterministic execution, etc.
If anyone else is interested in these topics, please let me know.
Paul Borman
Principal Technologist
Wind River Systems
