On Sun, Jun 13, 2010 at 11:23:45PM -0600, Grant Likely wrote: > >> Or perhaps the MMU and caches can be turned off for the duration of the > >> callback. > >> I don't have the details of ARM MMUs and caches reloaded into my head > >> yet. Maybe next week...
We've had these kinds of questions in the past. Doing what you're asking above is not really an option - it requires: 1. disable all IRQs 2. setup 1:1 MMU mappings for code to turn off MMU (requires new page table) 3. disable imprecise exceptions 4. flush caches and TLBS 5. jump to 1:1 mapping area for code to disable MMU 6. disable caches and mmu 7. call function 8. flush caches and TLBs 9. re-enable caches and mmu 10. re-enable imprecise exceptions 11. switch back to original MMU mappings 12. re-enable all IRQs This is fine if you don't care at all about interrupt latency. Unfortunately, most people do care about interrupt latency because that directly affects interactivity and system performance. The called function could not enable interrupts or exceptions - as the CPU vectors are in virtual space, disabling the MMU effectively makes them disappear. Moreover, with the MMU and caches disabled, the CPU performance is extremely poor, so the called function will run slowly. So, disabling the MMU isn't really viable. Now, if the external code was fully PIC, we could then run it with the MMU enabled. However, this wouldn't really help - the external code could not access any devices without knowledge of how the kernel setup the V:P translations. So you'd need to pass some kind of data structure giving locations of devices to the called code - but then what if the kernel doesn't have the device mapped? _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev