[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 :
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.
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
Is there any big downside I don't see there?
If not, I would pick this solution to implement the virtual memory
I could modify the MMU to do that, but I would prefer keeping the entire
4 GB address space for user space :)
2) Keep parts of the address space untranslated
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
3) Lock important pages into the TLB
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).
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.
Maybe some other interesting structures?
Thank you so much :)
Main Index |
Thread Index |