Hello Philip, great to hear that the LM32 MMU project moves forward!
> This leaves the problem of memory mapping. Whenever we change the > mapping, we will need to flush the ICACHE and DCACHE... Other than that, > the only potential issue is the instruction pipeline -- to deal with > that, we add a few NOPs after the cache flush requests, and keep the > Kernel stuff in a fixed area of memory (read as: the kernel remains > static in both virtual and physical space; user code may move around as > the memory allocator deems necessary). from the OS point of view, virtually indexed caches without taking physical addresses into account are a nightmare. It would be much better to use physical addresses as cache indices. Apart from alleviating the need to flush caches on context switches, cache inconsistencies (which are extremely hard to debug) become impossible to occur. If for some reason, the use of physical addresses as indices for the cache is not possible, tagging cache lines with a task ID would be a viable alternative: A cache hit is considered only if the address matches and the cache line's tag equals the value of a task-ID register (which gets changed when the kernel switches address spaces). This way, when switching address spaces back and for, untouched cache lines remain populated. BTW, I really like the MMU as implemented in Xilinx' MicroBlaze (in particuar the way of how tagged TLB entries can be installed and flushed to/from the software-loaded TLB, and the support for a wide range of different page sizes). We have ported our microkernel-based OS (Genode) to the MicroBlaze CPU, which was a very positive experience. The handling of usermode and privileged mode is quite simple and useful: As soon as the CPU switches to privileged mode, virtual memory gets disabled altogether. Hence, kernel code runs in physical mode and page faults in the kernel cannot occur by definition. The best: the kernel does not consume precious TLB entries. Furthermore, the whole virtual address space can be used for the user program without the need to dedicate an area to the kernel (virtualization comes in mind...). Cheers Norman _______________________________________________ http://lists.milkymist.org/listinfo.cgi/devel-milkymist.org IRC: #milkymist@Freenode Twitter: www.twitter.com/milkymistvj Ideas? http://milkymist.uservoice.com
