🚀 go-pugleaf

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