On 08/06/14 13:15, BALATON Zoltan wrote:
On Sat, 7 Jun 2014, BALATON Zoltan wrote:
I'm not sure how it should work but on real hardware the mapped area seems to be 0x0000-0x3000 while with OpenBIOS it's only 0x1000-0x3000. Could we just modify it to be 0x2000-0x3000 to avoid the exception? Or can we match what's on real hardware?
Alternatively maybe the translation could be locked in using dbat registers as maybe the DSI happens because the entry is not in the TLB any more by the time it is accessed. Please decide on one solution and let me know which one you prefer.
Actually just thinking about this, I've just remembered that in OpenBIOS we use a round-robin hash table slot eviction scheme that forces a tlbie (i.e. invalidate the TLB entry) at the end so perhaps we are invalidating the entry early? See arch/ppc/qemu/ofmem.c in hash_page32().
Quick and dirty hack alert: you may be able to tweak the code so that any hash entry with a virtual address which references physical page 0 is never chosen for eviction (and hence never forcibly invalidated with tlbie) and see if that helps at all? Have a play and see what happens.
I'd really like to get this in before the freeze because it is probably the biggest obstacle now preventing more people to try running MorphOS on QEMU. (The other one is in QEMU but that's less prohibiting because unlike building OpenBIOS that does not need a cross-compiler environment.)
Understood. I appreciate the time you have spent working on this, we just need to make sure that we don't just scatter MorphOSisms around the code in a way that makes maintenance harder for those of us who won't run it everyday, and isn't detrimental to all the other supported architectures.
ATB,
Mark.