From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1CfEug-0000Zz-0V for qemu-devel@nongnu.org; Fri, 17 Dec 2004 05:00:42 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1CfEue-0000Ym-8u for qemu-devel@nongnu.org; Fri, 17 Dec 2004 05:00:41 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CfEud-0000YH-3e for qemu-devel@nongnu.org; Fri, 17 Dec 2004 05:00:39 -0500 Received: from [64.233.184.204] (helo=wproxy.gmail.com) by monty-python.gnu.org with esmtp (Exim 4.34) id 1CfEfx-0005lH-ME for qemu-devel@nongnu.org; Fri, 17 Dec 2004 04:45:29 -0500 Received: by wproxy.gmail.com with SMTP id 68so12004wri for ; Fri, 17 Dec 2004 01:45:28 -0800 (PST) Message-ID: Date: Fri, 17 Dec 2004 10:45:28 +0100 From: Piotras Subject: Re: [Qemu-devel] softmmu thoughts In-Reply-To: <41C20947.8060808@bellard.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <1098217677.26133.26.camel@kubu.opensource.se> <4175B3CA.9050209@sti.net> <41765D06.4020006@bellard.org> <41C20947.8060808@bellard.org> Reply-To: Piotras , qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Fabrice Bellard , qemu-devel@nongnu.org Hi! On Thu, 16 Dec 2004 23:16:39 +0100, Fabrice Bellard wrote: > Hi, > > Here are a few points to look at: > > 1) MMU_MAP -> SOFT_MMU transition : more work is needed there, but I > will look at it too, but not in the near future (I think the best > solution is to recompile the TB directly in the fault handler - the goal > is to suppress 'HF_SOFTMMU_MASK' which slows down the emulator). This sounds reasonable. > 2) Try to make a Windows port. It seems doable because when you create a > 64 KB mapping in Windows you can select which 4 KB subpages are mapped. At present I don't have Windows development environment -- I don't even have Windows at home). Maybe someone could volunteer here? > 3) Test it with the ppc emulation if not already done. This will be my priority. It would be also nice to try PPC host. > 4) Use assembly code in most of the SOFTMMU code to accelerate unaligned > and I/O accesses (the current code is not optimized). This is nice future project, but not relevant for this patch. > 5) For you and me: reduce the number of ifdefs for SOFTMMU/MMU_MAP and > mmap(). Agreed. > 6) You can go even faster (at least on Linux or *BSD) by using hard mmu > for pages between 0 and a given address 'L' by using mmap() and by using > segment limits. You can fall back to MMU_MAP if the address is >= 'L', > and fall back to soft MMU if I/O accesses are done. The advantage is > that the 'code copy' mode can be used in that case, so you get closer to > 1:1 performance on most of the user code. Also it would be nice to investigate possibility to setting up two LDT entries -- one for accessing 0-"L" memory range and another for accessing "L1"-0xffffff range (using expansion direction flag of segment descriptor). Probably it could be possible to mix two in single TB (one for data and other for stack access). However at present I'm more interested in non-code-copy case. > Fabrice. Regards, Piotrek