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

[Yann Sionneau <yann.sionneau%gmail.com@localhost>]

Thank you all for your answers :)

Le 30/05/13 22:45, Eduardo Horvath a écrit :
> On Wed, 29 May 2013, Yann Sionneau wrote:
>
> > Hello NetBSD fellows,
> >
> > As I mentioned in my previous e-mail, I may need from time to time a little
> > bit of help since this is my first "full featured OS" port.
> >
> > I am wondering how I can manage virtual memory (especially how to avoid tlb
> > miss, or deal with them) in exception handlers.
> There are essentially three ways to do this.  Which one you chose depends
> on the hardware.
>
> 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.
> 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 :)
> 3) Lock important pages into the TLB
That's pretty easy to do for locking exception vectors in ITLB since 
vectors are contiguous in memory.
Locating every data I need to access to from exception vectors in the 
same couple of pages is not so easy I guess.
Moreover, locking a few TLB entries would mean that those virtual 
addresses ( a few pages ) would not be mappable for user space use since 
I could not eject those entries from the TLB.
I would prefer not locking any TLB entry to have it all available for 
mapping things for user space.
Moreover that would complexify even further TLB management in the vm 
subsystem.
> [...]
>
> 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).
Maybe some other interesting structures?
> Eduardo
Thank you so much :)

Best regards,

--
Yann Sionneau