On 28.10.2010, at 01:32, Torbjorn Granlund wrote: > Alexander Graf <ag...@suse.de> 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
