tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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

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?
Thank you so much :)

Best regards,

Yann Sionneau

Home | Main Index | Thread Index | Old Index