Re: [Qemu-devel] softmmu thoughts

[Elefterios Stamatogiannakis <estama@dblab.ece.ntua.gr>]

  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