From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IgPTw-00069L-OB for qemu-devel@nongnu.org; Fri, 12 Oct 2007 14:43:32 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IgPTv-00068v-W0 for qemu-devel@nongnu.org; Fri, 12 Oct 2007 14:43:32 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IgPTv-00068p-SB for qemu-devel@nongnu.org; Fri, 12 Oct 2007 14:43:31 -0400 Received: from sp604005mt.neufgp.fr ([84.96.92.11] helo=smtp.Neuf.fr) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1IgPTv-0002gp-Hi for qemu-devel@nongnu.org; Fri, 12 Oct 2007 14:43:31 -0400 Received: from [86.73.70.193] by sp604005mt.gpm.neuf.ld (Sun Java System Messaging Server 6.2-5.05 (built Feb 16 2006)) with ESMTP id <0JPT00KMWADL2100@sp604005mt.gpm.neuf.ld> for qemu-devel@nongnu.org; Fri, 12 Oct 2007 20:36:57 +0200 (CEST) Date: Fri, 12 Oct 2007 20:36:32 +0200 From: Fabrice Bellard Subject: Re: [Qemu-devel] RFC: Code fetch optimisation In-reply-to: Message-id: <470FBEB0.70606@bellard.org> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 7BIT References: <1192178037.9976.259.camel@rapid> 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 Blue Swirl wrote: > On 10/12/07, J. Mayer wrote: >> Here's a small patch that allow an optimisation for code fetch, at least >> for RISC CPU targets, as suggested by Fabrice Bellard. >> The main idea is that a translated block is never to span over a page >> boundary. As the tb_find_slow routine already gets the physical address >> of the page of code to be translated, the code translator could then >> fetch the code using raw host memory accesses instead of doing it >> through the softmmu routines. >> This patch could also be adapted to RISC CPU targets, with care for the >> last instruction of a page. For now, I did implement it for alpha, arm, >> mips, PowerPC and SH4. >> I don't actually know if the optimsation would bring a sensible speed >> gain or if it will be absolutelly marginal. >> >> Please comment. > > This will not work correctly for execution of MMIO registers, but > maybe that won't work on real hardware either. Who cares. It can never happen because QEMU currently does not support it (see get_phys_addr_code()). I started to implement it but never really finished it (real hardware can do it so QEMU should support it). The idea consist in using a reserved ram page to store the code. Another point is that the TB must be discarded once executed as the MMIO data can change. Regards, Fabrice.