![]() ![]() ![]() Here's the thing though: without knowing how the rest of the OS handles the HPT, this entire approach is unlikely to be stable. When he launched SheepShaver after playing Doom for a while, either the game had caused enough page table churn to evict those identity mappings, or the allocation ended up somewhere else where it didn't collide with any identity mappings that had ever existed, and thus SheepShaver worked. Either that or the fixed mapping doesn't cover all RAM, and for whatever reason never collides with the allocated pages on lower-RAM systems. My guess is that boxes with lower RAM have enough page table churn that those fixed mappings often go away. Instead, the mappings thrash on collisions. Why did this work with less RAM? Well, PPC uses hashed page tables, so they do not contain a full view of all MMU mappings. Of course, this then fails if SheepShaver ends up with EA=PA on the malloc out of sheer luck :-) However, if that is not trivial for some reason, then the next best solution would be to assume that the only other possible mapping for the pages is indeed a 1:1 identity map (they should really investigate where this comes from), and filter out any PTEs found during the search that map 1:1, since no legitimate userspace process should have these freshly allocated pages mapped down there anyway. The correct fix here is obviously to read the segment register instead of trying to do all this linear search heuristic. Lots of OSes map all RAM 1:1 to some extent. The other mapping is an identity mapping (PA=EA), as evidenced when the attempt to map EA 0 using that VSID found a PTE that mapped it to PA 0. Basically, what's going on is the code is taking a shortcut to properly figuring out how to locate its own page table mapping, and instead blindly searching the entire page table for all mappings from any process to the target pages, assuming it will be the owner. ![]()
0 Comments
Leave a Reply. |