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

[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

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

[Thiemo Seufer]

Paul Borman wrote:
> 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?

I think this goes in the more general area of instruction/cycle counting,
which would be also useful for basic performance analysis. IMHO the
alternatives should be switchable at runtime (from the monitor and via
command line), with host clock synchronization staying the default.

So far I haven't thought much about the other topics you raise.


Thiemo

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

[Even Rouault]

On Thursday 26 July 2007 18:34:36 Paul Borman wrote:
> 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.

As far as OpenGL is concerned, I don't know if you have already looked at it, 
but you may be interested by my OpenGL patch. Even if it uses a specific 
guest <--> host communication hack, this may save you the quite tidious 
process of serializing/deserializing OpenGL calls between guest and host.
For more details, see : http://qemu-forum.ipi.fi/viewtopic.php?t=2984

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

[andrzej zaborowski]

Hi,

On 26/07/07, Paul Borman <paul.borman@windriver.com> wrote:
> 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.

There is some interesting work being done on a similar project by Paul
Sokolovsky for his and Maria Zabolotnaya's Google Summer Of Project.
In their approach machine descriptions (but not only) are written in
python, which lets you hope that they can have a simple syntax,
practically like a config file, if desired, or a much more powerful
one, so it seems to be a better idea than plain config files.

Personally though I don't see much benefit to simple syntax config
files over C files, that are being used now.
Regards

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

[n schembr]

 
-snap-


>Personally though I don't see much benefit to simple syntax config 

>files over C files, that are being used now. 



Config files implies a self check process.  A better question might be, has qemu grown to the point where an outsider is going to define a new  platform?  

Could an arm based cell phone manufacture use the config files to define the hardware for the emulator without a full port? Iphone anyone :)

Nicholas A. Schembri 
state  college pa usa 


 










          

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

[Paul Borman]

The embedded space contains a vast number of boards, often only  
different by what devices are use, where they are located, etc.   
Building a new version of qemu for each board would be burdensome.   
The hope would be that we could build a generic qemu (for an  
architecture family), say, ppc_generic, which then read an external  
file (which, in our case, will be generated from board description)  
and configure itself according to that.  Further, by allowing devices  
to be loaded vi dlopen(), devices can be added after qemu has been  
built.  This would also allow the developer to specify the exact  
location of the device, rather than having a list of IRQ's and base  
ports, etc.

For the embedded world, yes, "outsiders" are certainly going to want  
to define new platforms and more than likely, provide their own  
custom devices.  They key is they do not need to muck with the real  
internals of qemu, just the part that picks the bits and pieces to use.

Oh, and if I am an outsider, then absolutely the answer is yes!, I  
already have had the need :-)

	-Paul

On Jul 26, 2007, at 3:48 PM, n schembr wrote:

>
> -snap-
>
>
>> Personally though I don't see much benefit to simple syntax config
>
>> files over C files, that are being used now.
>
>
>
> Config files implies a self check process.  A better question might  
> be, has qemu grown to the point where an outsider is going to  
> define a new  platform?
>
> Could an arm based cell phone manufacture use the config files to  
> define the hardware for the emulator without a full port? Iphone  
> anyone :)
>
> Nicholas A. Schembri
> state  college pa usa
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>

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

[Brian Johnson]

n schembr wrote:
> 
> -snap-
> 
>> Personally though I don't see much benefit to simple syntax config
>> files over C files, that are being used now.
> 
> Config files implies a self check process.  A better question might
> be, has qemu grown to the point where an outsider is going to define
> a new platform?

Absolutely.  I've been using it to prototype firmware for a NUMA 
chipset.  I've had to invent ugly command-line hacks for specifying the 
number of nodes, per-node consoles, etc.  And I still need to use a 
debugger to override variable values in my init. code when I want to 
test "odd" cases which my hacks don't support.  I could make good use of 
a generalized configuration file.

Brian

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

[Paul Sokolovsky]

Hello Paul,

Friday, July 27, 2007, 12:25:13 PM, you wrote:

> The embedded space contains a vast number of boards, often only  
> different by what devices are use, where they are located, etc.   
> Building a new version of qemu for each board would be burdensome.   
> The hope would be that we could build a generic qemu (for an  
> architecture family), say, ppc_generic, which then read an external  
> file (which, in our case, will be generated from board description)  
> and configure itself according to that.  Further, by allowing devices
> to be loaded vi dlopen(), devices can be added after qemu has been  
> built.  This would also allow the developer to specify the exact  
> location of the device, rather than having a list of IRQ's and base  
> ports, etc.

> For the embedded world, yes, "outsiders" are certainly going to want  
> to define new platforms and more than likely, provide their own  
> custom devices.  They key is they do not need to muck with the real  
> internals of qemu, just the part that picks the bits and pieces to use.

  Funnily, this is the same argumentation as I used more than
half-year ago when there was last big discussion on the need of
flexible and generalized config file:
http://lists.gnu.org/archive/html/qemu-devel/2006-10/msg00249.html
Then, it received rather cool response, I actually don't remember any
single vote for flexible/structural config and plugins. Well, I always
thought that just a small time will be required for more wider
audience to chime in and come back to this idea ;-).

> Oh, and if I am an outsider, then absolutely the answer is yes!, I  
> already have had the need :-)

>         -Paul

[]

-- 
Best regards,
 Paul                            mailto:pmiscml@gmail.com