From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Czdaf-0002Dk-AX for qemu-devel@nongnu.org; Fri, 11 Feb 2005 11:24:21 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Czdad-0002DK-Ke for qemu-devel@nongnu.org; Fri, 11 Feb 2005 11:24:21 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Czdad-0002DH-E2 for qemu-devel@nongnu.org; Fri, 11 Feb 2005 11:24:19 -0500 Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com) by monty-python.gnu.org with esmtp (Exim 4.34) id 1CzdN9-0001v4-Kx for qemu-devel@nongnu.org; Fri, 11 Feb 2005 11:10:23 -0500 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j1BG9Alu026898 for ; Fri, 11 Feb 2005 17:09:11 +0100 (MET) Received: (from dfawcus@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id QAA25037 for qemu-devel@nongnu.org; Fri, 11 Feb 2005 16:09:10 GMT Date: Fri, 11 Feb 2005 16:09:10 +0000 From: Derek Fawcus Subject: Re: [Qemu-devel] The QEMU Accelerator Module Message-ID: <20050211160909.G12093@mrwint.cisco.com> References: <420BEEB7.1010906@bellard.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <420BEEB7.1010906@bellard.org>; from fabrice@bellard.org on Fri, Feb 11, 2005 at 12:31:03AM +0100 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 Well, rather than whinging because Fabrice has not chosen to distribute his work under your preferred licence. People could simply reimplement it. Mind - this involves effort on their behalf, and some thinking. So it's certainly easier to moan. However I suggest that such moaning is simply a waste of time and effort. Now I don't know how Fabrice has done the kqemu module, but the obvious approach that springs to mind is simply moving the qemu-fast processing into the kernel with checks for the address boundary. So if I was to attempt to reimplement it, my starting point would be to approach it in that fashion. Namely placing a version of cpu_exec() and/or main_loop() into the kernel together with the use of the USE_CODE_COPY facility and some bounds checks such that if the machine being emulated attempted to have accessable memory above 0xc0000000 it would fall back to the user-space SOFT_MMU emulation. One could then manipulate the process space such that while the kernel module was running user space code, it's process address space (< 0xc0000000) reflected the emulated machine space. However, I've got other things to do, so the above is not a priority, and I'm quite happy to use Fabrice's module. Mind - I need to update to a more recent version of the code, my current work is in a version dating back to ~ September / October last year. DF