From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19PT6C-0000II-CW for qemu-devel@nongnu.org; Mon, 09 Jun 2003 16:18:36 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19PT6A-0000Hs-Ox for qemu-devel@nongnu.org; Mon, 09 Jun 2003 16:18:35 -0400 Received: from smtp6.wanadoo.fr ([193.252.22.28] helo=mwinf0301.wanadoo.fr) by monty-python.gnu.org with esmtp (Exim 4.20) id 19PT6A-0000Ha-AJ for qemu-devel@nongnu.org; Mon, 09 Jun 2003 16:18:34 -0400 Received: from free.fr (unknown [80.14.188.129]) by mwinf0301.wanadoo.fr (SMTP Server) with ESMTP id 0C5DC4007D8 for ; Mon, 9 Jun 2003 22:18:33 +0200 (CEST) Message-ID: <3EE4EB88.5000203@free.fr> Date: Mon, 09 Jun 2003 22:18:16 +0200 From: Fabrice Bellard MIME-Version: 1.0 Subject: Re: [Qemu-devel] simulated memory instead of host memory References: <20030609203126.7fc1bb17.jrydberg@night.trouble.net> <3EE4DB71.3090706@free.fr> <20030609213710.03f5677b.jrydberg@night.trouble.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , To: qemu-devel@nongnu.org Johan Rydberg wrote: > This is what my code generator emits for a memory store. The value that > should be stores is located in %ebx. The virtual address in %eax. > %ecx must be pushed on the stack to free a register. > > 40017160: 0000005b: push %ecx > 40017161: 0000005c: mov 0x805cce4,%ebp pointer to mtcache > 40017167: 00000062: mov %eax,%ecx > 40017169: 00000064: shr $0xc,%ecx > 4001716c: 00000067: and $0xff,%ecx 256 entries > 40017172: 0000006d: lea 0x0(%ebp,%ecx,8),%esi mtcache entry at %esi > 40017176: 00000071: mov %eax,%ecx > 40017178: 00000073: and $0xfffff000,%ecx make tag > 4001717e: 00000079: cmp %ecx,0x0(%esi) and compare > 40017181: 0000007c: jne 0x00000439 miss -> slow way > 40017187: 00000082: mov 0x4(%esi),%esi > 4001718a: 00000085: add %eax,%esi > 4001718c: 00000087: mov %ebx,0x0(%esi) do the store > 4001718f: 0000008a: pop %ecx > > Can you come to thing of a faster way to do it? Note that I generate > the code by hand (not using GCC). Using a cache as you do is a good idea. You can save some insns, and more if you use differents bits of the address (do a mask with 0x7f8), but you would have less cache hits. 40017160: 0000005b: push %ecx 40017167: 00000062: mov %eax,%esi 40017169: 00000064: shr $0xc,%esi movl %esi, %ecx 4001716c: 00000067: and $0xff,%esi 256 entries 4001717e: 00000079: cmp %ecx,0x805cee4(%esi,8) compare 40017181: 0000007c: jne 0x00000439 miss -> slow way 40017187: 00000082: add 0x805cee8(%esi,8),%eax 4001718c: 00000087: mov %ebx,0x0(%eax) do the store 4001718f: 0000008a: pop %ecx I guess GCC should give nearly optimal code. > : 3) An even faster solution is to use Linux memory mappings to emulate > : the MMU. The Linux MM state of the process would be considered as a TLB > : of the virtual x86 MMU state. It works only if the host has <= 4KB page > : size and if the guest OS don't do any mapping in memory >= 0xc0000000. > : With Linux as guest it would work as you can easily change the base > : address of the kernel. The restriction about mappings >= 0xc0000000 > : could be suppressed with a small (but tricky) kernel patch which would > : allow to mmap() at addresses >= 0xc0000000. > > Since it isn't very portable I don't think it is an option. Well, if you generate code it is already not portable :-) Fabrice.