From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1EyC61-0005qj-0O for qemu-devel@nongnu.org; Sun, 15 Jan 2006 12:55:17 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1EyC60-0005pt-2d for qemu-devel@nongnu.org; Sun, 15 Jan 2006 12:55:16 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EyC5z-0005pj-UH for qemu-devel@nongnu.org; Sun, 15 Jan 2006 12:55:16 -0500 Received: from [84.96.92.55] (helo=smtP.neuf.fr) by monty-python.gnu.org with esmtp (Exim 4.34) id 1EyC9M-0000ZU-Pp for qemu-devel@nongnu.org; Sun, 15 Jan 2006 12:58:44 -0500 Received: from [84.102.211.119] by sp604004mt.gpm.neuf.ld (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTP id <0IT50098KB05Y720@sp604004mt.gpm.neuf.ld> for qemu-devel@nongnu.org; Sun, 15 Jan 2006 18:52:54 +0100 (CET) Date: Sun, 15 Jan 2006 18:55:08 +0100 From: Fabrice Bellard Subject: Re: [Qemu-devel] Qemu - where will it go? In-reply-to: <200601141132.03700.info@j-pfennig.de> Message-id: <43CA8C7C.6010704@bellard.org> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: QUOTED-PRINTABLE References: <200601141132.03700.info@j-pfennig.de> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Hi, Using legacy apps is clearly an interesting topic for QEMU. With the= =20 improved dynamic translator written by Paul Brook (but not merged yet= ),=20 QEMU will be far less dependent of C compiler and porting the dynamic= =20 translator to a new host will still be simple. Fortunately (or not !)= ,=20 it is very likely that the x86 hosts will prevail for many years, so = the=20 dynamic generation back end won't need much change for some time. I am currently interested by improving the performance of QEMU for th= e=20 x86 target and host thru the accelerator and better device drivers (n= on=20 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 recompili= ng=20 QEMU, config files, single binary for all targets - GUI I believe that QEMU can stay "small" while containing all these featu= res. Fabrice. Juergen Pfennig wrote: > Hello dear readers, >=20 > 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=20 > 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. >=20 > Commercial vm solutions cannot really do that - as they are not ope= n source you > only move the dependecies from hardware to a software vendor. Both = usually > become unavailable over time. Hardware vitualization (xen, vanderpo= ol) is also > not an ideal long-term solution, you become again hard-ware dependi= ng... >=20 > This is what makes qemu so interesting for industry and business. >=20 > But a lot of work would have to be done. The next steps of developm= ent would > probably include: >=20 > - 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 implementatio= n > - 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). >=20 > So you see: in a commercial and or industrial application one woul= d like to run=20 > the qemus on a server. At least the MS remote desktop protocol shou= ld work > well. A qemu specific client would be nicer.=20 >=20 > Please do not try to make the current qemu program a better GUI app= lication - > do it the other way: move SDL out of qemu and write an extra client= app! >=20 > I did not find any information concerning the plans that the mainta= iners of > qemu have. >=20 > - currently it is simple and easy to understand. It has supringly f= ew lines > of code. > - the concept would allow for better performance (dynamic code gene= ration > 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 w= indows > apps. Word and friends run slowly as the cache runs full and gets= =20 > rebuilt too often. The current implementation may lead to degener= ation, > 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 si= de. >=20 > Unfortunately implementing the things that I was talking about woul= d blow > up the size of the code base dramatically. Qemu would never again b= e > small, pretty and easy to understand. Where do you want to go? >=20 > Yours J=C3=BCrgen >=20 >=20 > _______________________________________________ > Qemu-devel mailing list > Qemu-devel@nongnu.org > http://lists.nongnu.org/mailman/listinfo/qemu-devel >=20 >=20