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

[Eduardo Horvath <eeh%NetBSD.org@localhost>]

On Mon, 3 Jun 2013, Yann Sionneau wrote:

> Thank you all for your answers :)

No prob.
 
> 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?

Donno.  Depends on your hardware.  I'm aware of some hardware designs 
where caches where you need to have the MMU enabled to use the caches.  If 
your hardware doesn't have any weird quirks like that then turning off the 
MMU may well be a good solution.

> 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 :)

Yeah.  Well.  Thing is, some architectures, like MIPS, implicitly assume 
this sort of thing, so thier ports implement things like 
copyin()/copyout() using that feature.

> > 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.

So your MMU doesn't support multiple address space IDs?  That sux.  That 
means you need to blow away the entire MMU each time you switch processes.

If you do have ASIDs, I like to reserve one for the kernel.  That way you 
don't need to share the address space with userland.  

Eduardo