Re: [Qemu-devel] softmmu thoughts

[Magnus Damm]

Hello there, 

Thanks for the reply!

On Wed, 2004-10-20 at 02:13, Piotras wrote:
> Hi!
> 
> I experimented already with similar approach. I started with Qemu-fast as it 
> already uses signal handler and mmap to setup guest address space.
> 
> Qemu-fast requires that virtual address space visible inside emulator is 
> mapped 
> directly to qemu process address space. Because of this qemu-fast uses 
> special 
> memory layout. This means that it will always be much less portable than 
> qemu-softmmu, but on the other hand is much faster and can support code-copy 
> to achieve near-native performance.

I've never tried qemu-fast because I mostly use a powerpc machine. And I
like to avoid patches for the guest.

> The goal of my experiment was to evaluate possibility of using mmap-ed memory 
> to improve speed of softmmu without introducing portability limitations of 
> Qemu-fast. 

Exactly my goal too. But you actually did something useful! =)

> The memory access is implemented in 4 x86 instructions:
>     asm volatile (
>         "mov    %3, %%eax\n"
>         "shr    %2, %%eax\n"
>         "mov    %1(%%ebp,%%eax,4), %%eax\n"
>         "movl   (%3,%%eax,1), %0\n"
>         : "=r" (result)
>         : "m" (*(uint8_t *)offsetof(CPUX86State, indirection_table[0])),
>           "I" (MAP_BLOCK_BITS),
>           "r" (virtual_addr)
>         : "%eax");
> Only the last instruction can fail. Whenever the signal handler modifies the 
> indirection_table entry, the new value is stored in the EAX register.
> On instruction
> restart the new value is used.

It seems like you put some thought into this... Smart idea to
precalculate the indirection table to avoid the and operation.

> I believe that MAP_BLOCK_BITS should be set to value bigger then 12 to limit 
> size of indirection_table and fragmentation of memory map (mmaped pages).
> 
> IIRC, the nbench results were about 20-30% better then traditional
> Qemu-softmmu.
> Also Linux seemed faster. However Windows 98 seemed much slower. The problem 
> with Windows is that it does a lot of writes on the very same pages that the 
> code is executing from and this causes a lot of page faults.
> 
> I'm attaching the patch. It's very experimental so you may expect bugs.

Ok, thanks! Good work!

/ magnus