qemu-devel
[Top][All Lists]
Advanced

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

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


From: Fabrice Bellard
Subject: Re: [Qemu-devel] Qemu - where will it go?
Date: Sun, 15 Jan 2006 18:55:08 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040913

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
address@hidden
http://lists.nongnu.org/mailman/listinfo/qemu-devel








reply via email to

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