[Qemu-devel] QEmu as a Device Software Optimization tool

[Paul Borman]

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