tech-kern archive

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

[Milkymist port] virtual memory management



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.

At first my idea was to do most of the low level stuff in exception handlers with MMU turned off, I was told it was a very bad idea. LM32 MMU (for now at least) turns itself off upon any CPU exception, therefore I plan on turning it on right away in the exception handler.

This leads to the following scenario I don't know how to deal with:

1°) some code somewhere generates an I(nstruction) TLB miss in the MMU, this leads to a CPU exception, CPU then branches immediately to the "ITLB miss" exception vector.

2°) I turn the MMU back on in the exception vector.

What happens if the virtual address of "TLB miss" exception vector is currently not in the ITLB ?
We would "TLB miss" forever in loop, right?

Another scenario: let's assume that I update the ITLB with the virtual->physical of the "ITLB miss" exception vector before turning the MMU back on.

1°) some code somewhere generates a TLB miss in the MMU, this leads to a CPU exception, CPU then branches immediately to the "TLB miss" exception vector.

2°) I update the ITLB mapping of the "TLB miss" exception vector.

3°) I do some stuff like loading data from memory or storing data to memory

Then I would hit a D(ata) TLB miss which would generate a CPU exception, CPU would branch to "DTLB miss" exception vector.

4°) DTLB exception vector could then generate another DTLB miss exception for the same reason (loading from memory or storing to memory)

I am sorry I don't have much documentation to provide about the MMU (it is open source hardware though) but I would happily answer any question regarding it since I developed most part of it.

It is a very basic MMU, with no hardware page tree walker, it just has an ITLB and a DTLB, CPU caches are VIPT (virtually indexed physically tagged), I can update a TLB line, flush a line, or flush the entire TLB.

- The MMU can generate 3 types of CPU exceptions: ITLB miss (virtual address of fetched instruction not in the ITLB), DTLB miss (virtual address of stored/loaded memory location not in the DTLB) and DTLB fault (a memory store on a virtual address whose TLB entry is VALID and marked as READ-ONLY).

- Software has to take care of all the TLB management (flushing and updating TLB). - The MMU turns itself OFF upon any exception (divide by zero, interrupt, bus error, tlb miss, dtlb fault, hardware breakpoint etc). - The MMU turns itself back to its previous state (the state it has when the exception happened) upon execution of "eret" instruction (return from exception).

Thank you for your help :)

Cheers!

--
Yann Sionneau



Home | Main Index | Thread Index | Old Index