Re: [Milkymist-devel] [Milkymist port] virtual memory management

[David Holland <dholland-tech%netbsd.org@localhost>]

On Mon, Jun 03, 2013 at 10:11:14PM +0200, Yann Sionneau wrote:
 >> There are essentially three ways to do this.  Which one you chose depends
 >> on the hardware.

There's also a second issue you're overlooking, which is that you need
a way to access the user address space from the kernel.

 > >1) Turn off the MMU on exception
 >
 > That sounds like the better thing to do from my point of view, I
 > don't see any big downside apart from having to duplicate a few
 > pointers in a few structures to have both virtual and physical
 > addresses of some data structures like PCB, trapframes, page
 > tables.
 > 
 > Is there any big downside I don't see there?
 > If not, I would pick this solution to implement the virtual memory
 > subsystem.

There are two different architectures here: one is to run the entire
kernel with the MMU disabled; the other is to disable the MMU only for
the TLB refill handler. (And maybe for the entry points of other
exceptions too, or maybe not, but that's relatively unimportant.)

 > >2) Keep parts of the address space untranslated
 >
 > I could modify the MMU to do that, but I would prefer keeping the
 > entire 4 GB address space for user space :)

In this case you cannot set up the conventional scheme where the
kernel is mapped into the upper portion of all processes' address
spaces. You will then need to implement copyin/copyout using special
instructions or some other hardware-supported scheme to allow
accessing the user address space via the MMU while the MMU is
either disabled or mapping the kernel address space (as per my
previous paragraph).

I hope some such scheme exists, or, since I gather you're designing
the MMU as well as the pmap, you're willing to implement some such
scheme.

 > >3) Lock important pages into the TLB
 >
 > [...]

That is in general a bad idea. With a poorly conceived MMU it might be
necessary, but if you're inventing the MMU as well you don't need to 

 > >So you can implement your VM subsystem several different ways.  Just
 > >remember that on a TLB-only machine you need to make sure the MMU handlers
 > >can access the page tables, either bypassing the MMU or using some trick
 > >that does not result in recursive TLB faults.
 >
 > In my case, I guess I need to keep the MMU off while looking-up the
 > page table and to make sure I have physical address pointers in PCB
 > and in trap frames. I also need to have access to physical address
 > of curlwp (which therefore would give me access to physical address
 > of curpcb).

The TLB refill handler should only be a dozen or so instructions long.
You want to avoid going and looking at things like curlwp and curpcb.
All you should need is the base (physical) address of the page table,
which I'd encourage providing a hardware register to hold.

Also remember to consider the layout of your TLB entries from the
point of view of loading them from a page table using as few
instructions as possible.

Also in general it seems to me like you ought to stop for a bit and
nail down the overall design of the MMU and the virtual memory
environment before you go charging around implementing pmap code.
This was the basis of the questions I asked in my other email, except
you hadn't yet explained you were designing the MMU.

-- 
David A. Holland
dholland%netbsd.org@localhost