* Re: [Qemu-devel] softmmu thoughts
2004-12-16 12:22 ` Piotras
@ 2004-12-16 15:53 ` Elefterios Stamatogiannakis
2004-12-16 16:49 ` Jens Arm
` (2 more replies)
2004-12-16 22:16 ` Fabrice Bellard
2004-12-18 18:59 ` Magnus Damm
2 siblings, 3 replies; 12+ messages in thread
From: Elefterios Stamatogiannakis @ 2004-12-16 15:53 UTC (permalink / raw)
To: qemu-devel
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
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [Qemu-devel] softmmu thoughts
2004-12-16 15:53 ` Elefterios Stamatogiannakis
@ 2004-12-16 16:49 ` Jens Arm
2004-12-16 17:21 ` André Braga
2004-12-16 21:28 ` Piotras
2 siblings, 0 replies; 12+ messages in thread
From: Jens Arm @ 2004-12-16 16:49 UTC (permalink / raw)
To: qemu-devel
Hi
For me under Linux all is OK :)
Jens
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Qemu-devel] softmmu thoughts
2004-12-16 15:53 ` Elefterios Stamatogiannakis
2004-12-16 16:49 ` Jens Arm
@ 2004-12-16 17:21 ` André Braga
2004-12-16 21:28 ` Piotras
2 siblings, 0 replies; 12+ messages in thread
From: André Braga @ 2004-12-16 17:21 UTC (permalink / raw)
To: qemu-devel
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.
>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Qemu-devel] softmmu thoughts
2004-12-16 15:53 ` Elefterios Stamatogiannakis
2004-12-16 16:49 ` Jens Arm
2004-12-16 17:21 ` André Braga
@ 2004-12-16 21:28 ` Piotras
2004-12-16 21:43 ` Jim C. Brown
2 siblings, 1 reply; 12+ messages in thread
From: Piotras @ 2004-12-16 21:28 UTC (permalink / raw)
To: Elefterios Stamatogiannakis, qemu-devel
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Qemu-devel] softmmu thoughts
2004-12-16 21:28 ` Piotras
@ 2004-12-16 21:43 ` Jim C. Brown
0 siblings, 0 replies; 12+ messages in thread
From: Jim C. Brown @ 2004-12-16 21:43 UTC (permalink / raw)
To: Piotras, qemu-devel
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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Qemu-devel] softmmu thoughts
2004-12-16 12:22 ` Piotras
2004-12-16 15:53 ` Elefterios Stamatogiannakis
@ 2004-12-16 22:16 ` Fabrice Bellard
2004-12-17 9:45 ` Piotras
2004-12-18 18:59 ` Magnus Damm
2 siblings, 1 reply; 12+ messages in thread
From: Fabrice Bellard @ 2004-12-16 22:16 UTC (permalink / raw)
To: qemu-devel
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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Qemu-devel] softmmu thoughts
2004-12-16 22:16 ` Fabrice Bellard
@ 2004-12-17 9:45 ` Piotras
0 siblings, 0 replies; 12+ messages in thread
From: Piotras @ 2004-12-17 9:45 UTC (permalink / raw)
To: Fabrice Bellard, qemu-devel
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Qemu-devel] softmmu thoughts
2004-12-16 12:22 ` Piotras
2004-12-16 15:53 ` Elefterios Stamatogiannakis
2004-12-16 22:16 ` Fabrice Bellard
@ 2004-12-18 18:59 ` Magnus Damm
2 siblings, 0 replies; 12+ messages in thread
From: Magnus Damm @ 2004-12-18 18:59 UTC (permalink / raw)
To: Piotras; +Cc: qemu-devel
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.
>
>
>
^ permalink raw reply [flat|nested] 12+ messages in thread