Re: [Qemu-devel] softmmu thoughts

[Fabrice Bellard]

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 <address@hidden> 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 <address@hidden> 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.