Re: [Qemu-devel] Which qemu ports actually work?

[Alexander Graf]

On 28.10.2010, at 01:32, Torbjorn Granlund wrote:

> Alexander Graf <address@hidden> writes:
> 
>> Please also keep in mind that PPC emulation is _very_ slow.
>> 
>> Why is it slow?
> 
>  Because we're flushing the TLB on almost every MMU opcode.
> 
> OK.  Does that mean the TLB never gets more than a single entry?
> (I mean, do you flush the TLB before inserting a new entry into it?)
> 
> What is the reason for this flushing?

The PPC MMU works by translating an ea -> va -> ra. The qemu soft-tlb only 
knows about ea -> ra mappings. So while on real hardware, we can keep several 
contexts in the tlb, in qemu we flush it several times on every context switch. 
Basically every time the ea -> va mapping gets changed.

For details on how the PPC MMU works, please check my video on the KVM Forum 
2010 page.

Somehow we also end up flushing the translated code a lot, but I'll have to 
check the source to see why. It's probably related.

> 
> A related thing, related to cross endianess: I wrote a simulator many
> years ago (around 1990) that turned memory "upside down" for cross
> endianess.  I.e., a reference to address x was simulated as
> *(memend-opsize-x), where memend points to the end of the area
> simulating memory, opsize of the size in bytes of the operation.
> 
> The point of this is that one can use full-size native load or store
> instructions, instead of many byte operations and shifts.
> 
> I never published this idea, but I assume it has been rediscovered and
> is now a standard trick?

Endianness is not the issue really :). The MMU gives us way harder hits.


Alex