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

[Fabrice Bellard <fabrice@bellard.org>]

Hi,

Using legacy apps is clearly an interesting topic for QEMU. With the 
improved dynamic translator written by Paul Brook (but not merged yet), 
QEMU will be far less dependent of C compiler and porting the dynamic 
translator to a new host will still be simple. Fortunately (or not !), 
it is very likely that the x86 hosts will prevail for many years, so the 
dynamic generation back end won't need much change for some time.

I am currently interested by improving the performance of QEMU for the 
x86 target and host thru the accelerator and better device drivers (non 
blocking I/O patch, network with pcnet and DMA).

I have other topics on my TODO list but with a lower priority:

- better debugging features
- VNC server (merge the VNC patch)
- plugin system to develop new devices and machines without recompiling 
QEMU, config files, single binary for all targets
- GUI

I believe that QEMU can stay "small" while containing all these features.

Fabrice.

Juergen Pfennig wrote:
> 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
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
> 
>