From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1Cf4cz-0002Mn-95 for qemu-devel@nongnu.org; Thu, 16 Dec 2004 18:01:45 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1Cf4cy-0002MC-7c for qemu-devel@nongnu.org; Thu, 16 Dec 2004 18:01:44 -0500 Received: from [129.104.30.34] (helo=mx1.polytechnique.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1Cf3uz-0004Xf-Ie for qemu-devel@nongnu.org; Thu, 16 Dec 2004 17:16:18 -0500 Message-ID: <41C20947.8060808@bellard.org> Date: Thu, 16 Dec 2004 23:16:39 +0100 From: Fabrice Bellard MIME-Version: 1.0 Subject: Re: [Qemu-devel] softmmu thoughts References: <1098217677.26133.26.camel@kubu.opensource.se> <4175B3CA.9050209@sti.net> <41765D06.4020006@bellard.org> 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 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). 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. 3) Test it with the ppc emulation if not already done. 4) Use assembly code in most of the SOFTMMU code to accelerate unaligned and I/O accesses (the current code is not optimized). 5) For you and me: reduce the number of ifdefs for SOFTMMU/MMU_MAP and mmap(). 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. Fabrice. Piotras wrote: > Hi! > > I updated the patch to solve problems reported by Jens Arm: > * compilation problem on Mandrake 9.1 > * SEGV problem when working with non-TLS glibc. > Jens, thanks for your help! > > I also cleaned-up the code and comments in several places (for > example page_unprotect). > > The patch should apply cleanly to recent CVS. It should work > with 0.6.1 without problems too. > > > Regards, > > Piotrek > > On Tue, 14 Dec 2004 18:54:04 +0100, Piotras wrote: > >>Hi! >> >>I'm attaching a new patch based on your suggestions. On my machine >>nbench gives: >> memory index: 37% up >> integer index: 36% up >> fp index: 4% up >> >>The patch is divided in three files to simplify review. Part 1 contains >>mostly rearrangement existing code necessary for the patch. Part 2 >>adds the new mmu mode. Part 3 contains heuristic to optimize >>performance of iomem and self modifying code. >> >>To test the patch create a build directory and run: >> > tar -zxf _PATH_TO_qemu-0.6.1.tar.gz >> > tar -zxf _PATH_TO_linux-test-0.5.1.tar.gz >> > cd qemu-0.6.1 >> > ./configure --target-list=i386-softmmu >> > gunzip < _PATH_TO_mmu-part1.patch.gz | patch -p1 >> > gunzip < _PATH_TO_mmu-part2.patch.gz | patch -p1 >> > gunzip < _PATH_TO_mmu-part3.patch.gz | patch -p1 >> > make >> > ./i386-softmmu/qemu -m 64 -L pc-bios -hda ../linux-test/linux.img >> >>Last but not least. I'd like to acknowledge Magnus contribution -- VM >>setup code is derived from his work. >> >>Regards, >> >>Piotrek >> >>On Wed, 20 Oct 2004 14:41:42 +0200, Fabrice Bellard wrote: >> >>>Hi, >>> >>>The idea is interesting. Here are several suggestions: >>> >>>- It would be more efficient and simpler to map one 4KB host memory page >>>every 8 KB. Then you can have a fixed mmap() mapping (no syscall >>>overhead to change the mappings) and a simple way to handle unaligned >>>accesses. >>>- The critical point would be to keep standard soft MMU accesses for >>>device access. An architectural change is needed to do that, but it >>>seems easy to add. >>>- This patch should work with qemu, not qemu-fast. The future of >>>qemu-fast is to use a kernel module to have near native performances. It >>>is not worthwhile to invest time in soft MMU or dynamic translation when >>>you can just execute the code as is ! >>> >>>Fabrice.