Re: [Qemu-devel] softmmu thoughts

Re: [Qemu-devel] softmmu thoughts

[Piotras]

[-- Attachment #1: Type: text/plain, Size: 1775 bytes --]

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.

[-- Attachment #2: mmu-part1.patch.gz --]
[-- Type: application/x-tar, Size: 1953 bytes --]

[-- Attachment #3: mmu-part2.patch.gz --]
[-- Type: application/x-tar, Size: 8306 bytes --]

[-- Attachment #4: mmu-part3.patch.gz --]
[-- Type: application/x-tar, Size: 2506 bytes --]

Re: [Qemu-devel] softmmu thoughts

[Jens Arm]

> 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

One hunk is failing, if I try to patch newest CVS:

[tux@tux qemu]$ patch -p1 < ../mmu-part2.patch 
patching file Makefile.target
patching file configure
patching file cpu-exec.c
patching file exec.c
patching file mmu_map.c
patching file mmu_map.h
patching file mmu_map_templ.h
patching file osdep.c
patching file target-i386/cpu.h
patching file target-i386/exec.h
patching file target-i386/helper2.c
patching file target-i386/op.c
patching file target-i386/ops_template.h
patching file target-i386/ops_template_mem.h
patching file target-i386/translate.c
Hunk #12 succeeded at 4408 (offset 12 lines).
Hunk #13 succeeded at 4531 (offset 12 lines).
Hunk #14 succeeded at 4574 (offset 12 lines).
Hunk #15 succeeded at 4660 (offset 12 lines).
patching file vl.c
Hunk #1 succeeded at 1733 (offset 41 lines).
Hunk #2 FAILED at 2665.
Hunk #3 succeeded at 2739 (offset 50 lines).
Hunk #4 succeeded at 2818 (offset 50 lines).
Hunk #5 succeeded at 3170 with fuzz 2 (offset 74 lines).
Hunk #6 succeeded at 3247 (offset 74 lines).
Hunk #7 succeeded at 3281 (offset 74 lines).
Hunk #8 succeeded at 3399 (offset 76 lines).
1 out of 8 hunks FAILED -- saving rejects to file vl.c.rej

Jens

Re: [Qemu-devel] softmmu thoughts

[Jens Arm]

Hi


And if I get it patched I get:


make[1]: Entering directory `/home/tux/q/qemu/i386-softmmu'
gcc -Wall -O2 -g -fno-strict-aliasing -fomit-frame-pointer -I. -I/home/tux/q/qemu/target-i386 -I/home/tux/q/qemu -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -I/home/tux/q/qemu/slirp -c -o vl.o /home/tux/q/qemu/vl.c
In file included from /usr/include/signal.h:330,
                 from /usr/include/sys/ucontext.h:23,
                 from /home/tux/q/qemu/mmu_map.h:22,
                 from /home/tux/q/qemu/target-i386/cpu.h:34,
                 from /home/tux/q/qemu/vl.h:73,
                 from /home/tux/q/qemu/vl.c:24:
/usr/include/ucontext.h:32: parse error before '*' token
/usr/include/ucontext.h:35: parse error before '*' token
/usr/include/ucontext.h:39: parse error before '*' token
/usr/include/ucontext.h:48: parse error before '*' token
/usr/include/ucontext.h:48: `makecontext' declared as function returning a function
/usr/include/ucontext.h:49: parse error before "int"
make[1]: *** [vl.o] Fehler 1
make[1]: Leaving directory `/home/tux/q/qemu/i386-softmmu'
make: *** [all] Fehler 1


Jens

Re: [Qemu-devel] softmmu thoughts

[Piotras]

[-- Attachment #1: Type: text/plain, Size: 2326 bytes --]

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 <piotras@gmail.com> 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 <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.

[-- Attachment #2: v1-part1.patch.gz --]
[-- Type: application/x-tar, Size: 2057 bytes --]

[-- Attachment #3: v1-part2.patch.gz --]
[-- Type: application/x-tar, Size: 8421 bytes --]

[-- Attachment #4: v1-part3.patch.gz --]
[-- Type: application/x-tar, Size: 3120 bytes --]

Re: [Qemu-devel] softmmu thoughts

[Elefterios Stamatogiannakis]

  I tried to compile it under mingw and it failed. This patch is for 
linux only?

  (today's cvs with all three patches cleanly applied)
---------
$ gcc -dumpversion
3.2.3
---------
gcc -Wall -O2 -g -fno-strict-aliasing -fomit-frame-pointer -I. 
-I/c/Projects/qemu/target-i386 -I/c/Projects/qemu -D_GNU_SOURCE 
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -I/c/Projects/qemu/slirp -c 
-o vl.o /c/Projects/qemu/vl.c
In file included from c:/Projects/qemu/target-i386/cpu.h:34,
                  from c:/Projects/qemu/vl.h:73,
                  from c:/Projects/qemu/vl.c:24:
c:/Projects/qemu/mmu_map.h:22:22: ucontext.h: No such file or directory
In file included from c:/Projects/qemu/target-i386/cpu.h:34,
                  from c:/Projects/qemu/vl.h:73,
                  from c:/Projects/qemu/vl.c:24:
c:/Projects/qemu/mmu_map.h:112: parse error before '*' token
c:/Projects/qemu/mmu_map.h: In function `mmu_map_fault_get_vaddr':
c:/Projects/qemu/mmu_map.h:117: `addr' undeclared (first use in this 
function)
---------

teris.

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 <piotras@gmail.com> 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 <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.
>>>
>>>
>>>------------------------------------------------------------------------
>>>
>>>_______________________________________________
>>>Qemu-devel mailing list
>>>Qemu-devel@nongnu.org
>>>http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] softmmu thoughts

[Jens Arm]

Hi

For me under Linux all is OK :)

Jens

Re: [Qemu-devel] softmmu thoughts

[André Braga]

Maybe this could help?
http://www.codeproject.com/threads/ucontext.asp

There might be a working ucontext.h in the headers of UWIN as well,
you might want to check it out:
http://www.research.att.com/sw/tools/uwin/

I haven't tested neither, btw.


--
"A year spent in artificial intelligence is enough to make one believe in God"
Alan J. Perlis




On Thu, 16 Dec 2004 17:53:44 +0200, Elefterios Stamatogiannakis
<estama@dblab.ece.ntua.gr> wrote:
>   I tried to compile it under mingw and it failed. This patch is for
> linux only?
> 
>   (today's cvs with all three patches cleanly applied)
> ---------
> $ gcc -dumpversion
> 3.2.3
> ---------
> gcc -Wall -O2 -g -fno-strict-aliasing -fomit-frame-pointer -I. 
> -I/c/Projects/qemu/target-i386 -I/c/Projects/qemu -D_GNU_SOURCE
> -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -I/c/Projects/qemu/slirp -c
> -o vl.o /c/Projects/qemu/vl.c
> In file included from c:/Projects/qemu/target-i386/cpu.h:34,
>                   from c:/Projects/qemu/vl.h:73,
>                   from c:/Projects/qemu/vl.c:24:
> c:/Projects/qemu/mmu_map.h:22:22: ucontext.h: No such file or directory
> In file included from c:/Projects/qemu/target-i386/cpu.h:34,
>                   from c:/Projects/qemu/vl.h:73,
>                   from c:/Projects/qemu/vl.c:24:
> c:/Projects/qemu/mmu_map.h:112: parse error before '*' token
> c:/Projects/qemu/mmu_map.h: In function `mmu_map_fault_get_vaddr':
> c:/Projects/qemu/mmu_map.h:117: `addr' undeclared (first use in this
> function)
> ---------
> 
> teris.
>

Re: [Qemu-devel] softmmu thoughts

[Piotras]

Currently only Linux running on x86 hardware is supported for 
emulation of x86 guest (softmmu).


Regards,

Piotrek

On Thu, 16 Dec 2004 17:53:44 +0200, Elefterios Stamatogiannakis
<estama@dblab.ece.ntua.gr> wrote:
>   I tried to compile it under mingw and it failed. This patch is for
> linux only?
> 
>   (today's cvs with all three patches cleanly applied)
> ---------
> $ gcc -dumpversion
> 3.2.3
> ---------
> gcc -Wall -O2 -g -fno-strict-aliasing -fomit-frame-pointer -I. 
> -I/c/Projects/qemu/target-i386 -I/c/Projects/qemu -D_GNU_SOURCE
> -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -I/c/Projects/qemu/slirp -c
> -o vl.o /c/Projects/qemu/vl.c
> In file included from c:/Projects/qemu/target-i386/cpu.h:34,
>                   from c:/Projects/qemu/vl.h:73,
>                   from c:/Projects/qemu/vl.c:24:
> c:/Projects/qemu/mmu_map.h:22:22: ucontext.h: No such file or directory
> In file included from c:/Projects/qemu/target-i386/cpu.h:34,
>                   from c:/Projects/qemu/vl.h:73,
>                   from c:/Projects/qemu/vl.c:24:
> c:/Projects/qemu/mmu_map.h:112: parse error before '*' token
> c:/Projects/qemu/mmu_map.h: In function `mmu_map_fault_get_vaddr':
> c:/Projects/qemu/mmu_map.h:117: `addr' undeclared (first use in this
> function)
> ---------
> 
> teris.
> 
> 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

Re: [Qemu-devel] softmmu thoughts

[Jim C. Brown]

On Thu, Dec 16, 2004 at 10:28:58PM +0100, Piotras wrote:
> Currently only Linux running on x86 hardware is supported for 
> emulation of x86 guest (softmmu).
> 

Do you mean the just the patch?

softmmu works fine on win2k host, freebsd host, linux/PPC host ....

> 
> Regards,
> 
> Piotrek
> 
> On Thu, 16 Dec 2004 17:53:44 +0200, Elefterios Stamatogiannakis
> <estama@dblab.ece.ntua.gr> wrote:
> >   I tried to compile it under mingw and it failed. This patch is for
> > linux only?
> > 

-- 
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.

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 <piotras@gmail.com> 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 <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.

Re: [Qemu-devel] softmmu thoughts

[Piotras]

Hi!

On Thu, 16 Dec 2004 23:16:39 +0100, Fabrice Bellard <fabrice@bellard.org> wrote:
> 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).

This sounds reasonable.


> 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.

At present I don't have Windows development environment -- I don't 
even have Windows at home). Maybe someone could volunteer here?


> 3) Test it with the ppc emulation if not already done.

This will be my priority. It would be also nice to try PPC host.


> 4) Use assembly code in most of the SOFTMMU code to accelerate unaligned
> and I/O accesses (the current code is not optimized).

This is nice future project, but not relevant for this patch.


> 5) For you and me: reduce the number of ifdefs for SOFTMMU/MMU_MAP and
> mmap().

Agreed.


> 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.

Also it would be nice to investigate possibility to setting up two LDT
entries -- one for accessing 0-"L" memory range and another for 
accessing "L1"-0xffffff range (using expansion direction flag of segment 
descriptor). Probably it could be possible to mix two in single TB (one 
for data and other for stack access).

However at present I'm more interested in non-code-copy case.


> Fabrice.


Regards,

Piotrek

Re: [Qemu-devel] softmmu thoughts

[Magnus Damm]

Hello,

Your patch really rocks! I have applied the patch to CVS of today. The
guest OS is custom linux-2.6.9 with serial console. The host is Gentoo
Linux on Pentium M hardware, vanilla 2.6.9 kernel.

Running the guest inside QEMU with 32MiB RAM and -nographic gives me
the following performance gain compared to unpatched CVS of today:

memory index: 40% up
integer index: 36% up
fp index: 2% up

Thanks, keep up the good work!

/ magnus


On Thu, 16 Dec 2004 13:22:41 +0100, Piotras <piotras@gmail.com> 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 <piotras@gmail.com> 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 <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.
> 
> 
>