[Qemu-devel] Qemu - where will it go?

[Juergen Pfennig]

Hello dear readers,

as I found out qemu is quite stable and has acceptable performance. Using it you
could freeze legacy applications using a legacy OS like win 2003 or win XP. I am
talking of periods from 5 to 20 years! In a commercial environment it happens 
frequently that you would like to access old data but cannot do so because the
hardware is gone or the old software does not work with the current OS.

Commercial vm solutions cannot really do that - as they are not open source you
only move the dependecies from hardware to a software vendor. Both usually
become unavailable over time. Hardware vitualization (xen, vanderpool) is also
not an ideal long-term solution, you become again hard-ware depending...

This is what makes qemu so interesting for industry and business.

But a lot of work would have to be done. The next steps of development would
probably include:

- run qemu as a service (on Windows or on Linux using xinetd)
- make rdp (Win Terminal Server) work when qemu started via
  xinetd
- improve disk image format, better snapshot handling
- make a plugin architecture for the host side device implementation
- allow 'remote' host side devices (sound, usb, serial ...)
- define a protocol to use qemu over a network (should multiplex
  video, sound, usb, serial and so on).

So you see: in a commercial  and or industrial application one would like to 
run 
the qemus on a server. At least the MS remote desktop protocol should work
well. A qemu specific client would be nicer. 

Please do not try to make the current qemu program a better GUI application -
do it the other way: move SDL out of qemu and write an extra client app!

I did not find any information concerning the plans that the maintainers of
qemu have.

- currently it is simple and easy to understand. It has supringly few lines
  of code.
- the concept would allow for better performance (dynamic code generation
  could use optimization to eliminate inter module function calls, see some
  of the java jit propaganda).
- currently the code translation cache is a problem for old-style windows
  apps. Word and friends run slowly as the cache runs full and gets 
  rebuilt too often. The current implementation may lead to degeneration,
  e.g. a very low cache hit ratio.
- obviously a generational code translation cache should be used, e.g.
  frequently executed code would not be lost but would be promoted to
  the next generation cache. See the .net gc propaganda.
- Finally one could take some ReactOS drivers to get better perfor-
  mace by not going through hw emulation but by making the ReatOS
  drivers stubs that can call native implementations on the host side.

Unfortunately implementing the things that I was talking about would blow
up the size of the code base dramatically. Qemu would never again be
small, pretty and easy to understand. Where do you want to go?

Yours Jürgen