Subject: Re: SIR Reset with todays sources
To: Martin Husemann <martin@duskware.de>
From: Eduardo Horvath <eeh@NetBSD.org>
List: port-sparc64
Date: 03/28/2007 15:48:33
On Wed, 28 Mar 2007, Martin Husemann wrote:

> I guess what I was trying to make sure I understood correctly is: if cache
> has a matching VA, but MMU has no valid mapping, and our trap handling will
> not add one - how does the cache compare PA?

When the processor attempts to do a load, a L1$ and TLB lookup are started 
in parallel.  If the TLB lookup fails, a trap is taken. When the TLB 
lookup completes, the PA from the TLB is  compared to the tag in the L1$.  
If they match, data is returned from the L1$.  If they don't match, a 
cache miss occurs and a cache line fill is begun.  

> Since this all happens in parallel, I guess the mmu fault trap will happen,
> and we will not retry the instruction, but send a sigsegv to the process.

Assuming that address is out of bounds, that is true.  

If there's no mapping the TLB, then the MMU will take a MMU miss fault.
The trap hanldler will first try to look in the TSB for a matching entry 
and add it to the TLB.  If there is no TSB entry, the trap handler will 
look in the page tables for a mapping and add it to the TLB.  If there is 
no mapping in the page table, the trap handler will enter an NFO mapping 
into the MMU and retry the instruction.

If the faulting instruction is an NFO load, it will load a zero into the 
register and continue.  If it's any other instruction, the processor will 
take a protection fault.  The protection fault will call 
data_access_fault() which will call uvm_fault() to resolve it.  
uvm_fault() will either determine it's a segmentation violation and send a 
signal, or synthesize a new mapping which pmap will enter into the page 
tables, invalidate the old TLB entry, and the instruction will be retried.
We now get another MMU miss fault, and the entire process is repeated.

Throw in register windows to complicate the context save process, and 
that's basically the trap model we use.  Solaris and Linux handle register 
window issues by adding some extra trap entries and returns, but I thought 
it would be more efficient to explicitly handle those cases in-line in the 
main trap handling routines.  YMMV.

Eduardo