From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1D1vVC-0004pg-ND for qemu-devel@nongnu.org; Thu, 17 Feb 2005 18:56:10 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1D1vUk-0004NO-ON for qemu-devel@nongnu.org; Thu, 17 Feb 2005 18:55:42 -0500 Received: from [129.104.30.34] (helo=mx1.polytechnique.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1D1v0V-0004HJ-Az for qemu-devel@nongnu.org; Thu, 17 Feb 2005 18:24:27 -0500 Received: from [84.99.204.96] (96.204.99-84.rev.gaoland.net [84.99.204.96]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ssl.polytechnique.org (Postfix) with ESMTP id D615633198 for ; Fri, 18 Feb 2005 00:24:24 +0100 (CET) Message-ID: <421527EB.9060604@bellard.org> Date: Fri, 18 Feb 2005 00:25:31 +0100 From: Fabrice Bellard MIME-Version: 1.0 Subject: Re: [Qemu-devel] FreeOSZoo will stop March 1, 2005 References: <200502121018.09039.jm@poure.com> <20050217215350.GB1446@mail.13thfloor.at> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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 Grzegorz Kulewski wrote: > Hi, > > On Thu, 17 Feb 2005, Herbert Poetzl wrote: > >> On Sat, Feb 12, 2005 at 11:41:55PM +0100, Grzegorz Kulewski wrote: >> >>> Hi, >>> >>> On Sat, 12 Feb 2005, Jean-Michel POURE wrote: >>> >>>> Following Fabrice decision to transform QEMU into a proprietary closed >>>> solution >>> >>> >>> No, Fabrice did not transform QEMU into anything. He simply added >>> another >>> optional module than can make QEMU faster and more bug-free. You can >>> still >>> use QEMU without the accelerator and be perfectly happy with it. Also >>> any >>> further development in area of IO, devices and so on will make both >>> versions better. KQEMU is only very small accelerator. >> >> >> well, unfortunately together with the following mail ... >> >> | From: Fabrice Bellard >> | To: qemu-devel@nongnu.org >> | Date: Sat, 29 Jan 2005 22:48:24 +0100 >> | >> | Hi, >> | >> | I plan to remove the 'qemu-fast' target in the next release of QEMU. It >> | is too painful to maintain, difficult to port and it needs a patched >> | guest OS to work correctly. >> | >> | This target is replaced by the standard QEMU with soft mmu support. The >> | QEMU Kernel Acceleration Layer which will be unveiled very soon will >> | give much more performance while working with unpatched guest OSes. >> | >> | Fabrice. >> >> the future looks more like this: >> >> - you want the same performance or better as before? >> then you have to use 'my' proprietary kernel module >> which isn't even open source (so that somebody >> could verify that it isn't that evil ...) >> >> - of course, you can use the slow version and >> contribute to the development of the commercial? >> version ... > > > Well > > 1. qemu-fast is still there but disabled by default, > 2. qemu-fast used patched kernel and was very limited and probably buggy, > 3. you can use UML or plex86(?) for the same (== running Linux under > Linux), My decision to disable qemu-fast is not because I fear that there is some kind of concurrence with kqemu. I wanted to do that since a long time. Here are a few reasons: 1) I feel that running patched OSes is not a good target for QEMU. The strength of QEMU is to run unpatched OSes. Otherwise there are many other good solutions (Xen, UML, new plex86). qemu-fast was just a hack before I got convinced to implemented the soft mmu. 2) qemu-fast is difficult to maintain - it uses too many hacks to have full control over the address space. 3) qemu-fast is not safe (no address space protection). 4) qemu-fast performance is limited by the mmap() performance, especially in case of frequent process switches (try a kernel compilation !). qemu-fast can have some future, but it involves a lot of work and I don't have the time to do it yet. Here are a few ideas: - Use a separate process to run the translator so that the UI can run in its own address space with dynamic libraries. - Use segments limits to protect the translator code - Use kqemu to execute the translator in a separate address space. However, it is better to spend time on a better soft mmu (I plan to merge the last published patches for that) and on a better kqemu (when it will be GPLed). Fabrice.