Re: [Qemu-devel] Reporting Heisenbugs in qemu

[Blue Swirl]

On Wed, May 8, 2013 at 10:18 AM, Paolo Bonzini <address@hidden> wrote:
>
>> Paolo Bonzini <address@hidden> writes:
>>
>>   I guess that's the register windows.  There's only so much you can do to
>>   optimize them, and heavily recursive workloads (like Perl, or the RTL
>>   half of GCC) pay a hefty price.
>>
>> Two qemu targets stand out for slowness, sparc (32 and 64) and mips (64,
>> don't know about 32).
>>
>> x86 (32 and 64), arm, and ppc run with a slowdown of < 30 for my bogus
>> benchmark of GMP configure+make.
>>
>> With FreeBSD x86_64 I see a slowdown of just 13.  (My reference system
>> runs FreeBSD, so running FreeBSD under qemu is only far.)
>>
>> My claimed slowdown factors are affected by kernel, libraries, and
>> unfortunately very much by gcc speed, which vary with target.
>>
>> If the sparc emulation speed is due to register windows, then why does
>> mips seem just as slow?
>
> No idea. :)  Of all the architectures you listed, MIPS is really the one
> that I have no inkling of...
>
>> If register windows shortage is a problem, it should be easy to pretend
>> to have lots of them, right?
>
> That can help to avoid trapping to the kernel.  But you still have to
> spill the whole window to the stack on every call to a non-leaf function,
> which can be expensive even if you do it in the translated code.

The kernel wouldn't be able to spill or fill more than 8 windows
anyway. But maybe we could implement window cleaning in QEMU, if
nobody minds not seeing any CLEANWIN traps. I don't think real HW can
clean the windows.

Register window access in QEMU could be improved slightly, for example
it may be possible to handle wrapping of the registers with sparse
layout and page mapping tricks. Also the translator might be able to
keep track of current CWP and generate direct accesses instead of
going through regwptr.

>
> Paolo
>