[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Paul Borman
Subject: [Qemu-devel] QEmu as a Device Software Optimization tool
Date: Thu, 26 Jul 2007 12:34:36 -0400


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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]