Re: [Qemu-devel] simulated memory instead of host memory

[Fabrice Bellard <fabrice.bellard@free.fr>]

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.