From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1BWfps-0004Pg-A0 for qemu-devel@nongnu.org; Sat, 05 Jun 2004 14:24:04 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1BWfpq-0004P1-82 for qemu-devel@nongnu.org; Sat, 05 Jun 2004 14:24:03 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BWfpq-0004OY-1K for qemu-devel@nongnu.org; Sat, 05 Jun 2004 14:24:02 -0400 Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com) by monty-python.gnu.org with esmtp (Exim 4.34) id 1BWfog-00067c-4m for qemu-devel@nongnu.org; Sat, 05 Jun 2004 14:22:50 -0400 Received: from cisco.com (edinburgh.cisco.com [144.254.112.76]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i55IMj1P008334 for ; Sat, 5 Jun 2004 20:22:45 +0200 (MEST) Received: (from dfawcus@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id TAA08304 for qemu-devel@nongnu.org; Sat, 5 Jun 2004 19:22:45 +0100 (BST) Date: Sat, 5 Jun 2004 19:22:45 +0100 From: Derek Fawcus Subject: Re: [Qemu-devel] full speed ? Message-ID: <20040605192244.B1510@edinburgh.cisco.com> References: <200406051832.18282.vaise@votreservice.com> <40C1FFA1.5000804@dad-answers.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <40C1FFA1.5000804@dad-answers.com>; from hetz@dad-answers.com on Sat, Jun 05, 2004 at 08:15:13PM +0300 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 On Sat, Jun 05, 2004 at 08:15:13PM +0300, Hetz Ben Hamo wrote: > There are other plans to make it much faster (X86 on X86) but it > cannot be discussed it at the moment.. Cannot be discussed? Well the obvious approach is to split the program such that user mode code runs in a seperate process, then arrange for that process to be controlled by the main process as a debugee. Then the main process has complete control over the child, and can mess with it (including memory mappings, cataching signals and syscalls) to it's heart's content. This would allow user space to run at full speed, while still having the system space running in the emulated dynamic translation system. It'd take some work to do this, and get the synchronisation working correctly, but as I said it's the 'obvious' approach. It also has the advantage that it would work well on x86-64. DF