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 <fabrice@bellard.org> 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.