From: narad@nonsequitur.Eng.Sun.COM (Chuck Narad)
Newsgroups: comp.sys.sun.misc
Subject: Re: SPARC virtual to physical address translation
Date: 17 Aug 92 18:27:55 GMT
Reply-To: narad@nonsequitur.Eng.Sun.COM
Organization: Sun Microsystems
NNTP-Posting-Host: nonsequitur

In article 7K3@gumby.ocs.com, obi@gumby.ocs.com (Kuryan "Obi" Thomas) writes:
>Would some kind netperson please explain (by email if possible) how 32-bit
>virtual addresses are translated into physical addresses using the SPARC
>"reference MMU," whatever that is? I understand there is a two-level
>translation scheme, using a segment map and a page map. There's also
>something called a "context register." I'm clueless beyond this point.
>
>What I'd like to know specifically is:
>
>1. What is the context register? Is it something that establishes how a
>   particular process's virtual addresses are translated to physical?
>
>2. How does the two-level translation take place?
>
>3. What is the segment map? The page map? What is a page map entry group
>   (PMEG) and why are page map entries grouped?
>
>4. How are the 32 bits of a virtual address mapped to 32 bits of physical
>   address? (E.g., the low-order 12 bits is the offset in a page, the next
>   5 bits are the page number...that sort of thing).
>
>5. Any other nuggets of info you care to share.
>
>I'm just a curious user, so any level of detail and partial answers are
>welcome. I've been reading some of the papers in "The SPARC Technical
>Papers," (Springer-Verlag 1991) and I'm now more confused than I was
>before.
>
>Thank you for any and all responses. I'll post a summary if there's enough
>excitement.


First of all, the 2-level scheme that you describe is the 'Sun' MMU
which was used in Sun-2, Sun-3, Sun-4, and sun4c machines.  The MMU
was actually a cascaded set of SRAM which parsed the virtual address 
into segments and pages (and in one implementation a larger area
called regions).  The split among region, segment, and page was
implementation-specific.  These tables were manged by SW as a 
set of multi-level TLB's, and any miss or protection violation was
handled by the VM code in the OS.  Page sizes were 2K, 8K, and 4K
in different generations.

The PMEG was the intermediate index between the first and second
level of SRAM.

The Context Register allows each running process to have its own address
space.  Entries in the MMU are tagged by context number, and the current
context (value in the register) is used as part of the parsing information.
This allows the MMU to have the translations for several processes resident
at any time, thus supporting rapid switching between contexts.  Typical
implementations have 8-64 hardware contexts.  The OS must manage
removing a process from a context and assigning the context number
to a different process if that resource (number of contexts) runs dry.

The SPARC Reference MMU (SRMMU) was introduced along with SPARC V.8.
It is a TLB-based MMU design that uses tables in main memory to support
translation, and a set of TLB's in the processor to hold the current working
set of tranlsations.  The SRMMU takes a 32-bit virtual address and translates
it to a 36-bit physical address.  Included in the translation is a rich
set of protection modes, attributes such as 'cacheable', and referenced
and modified status.

SRMMU supports a large number of contexts, since that is no longer limited
by the size of fast SRAM.  Implementations in use today support 4K to 64K
active contexts.  The SRMMU supports 4 levels of table; if we correlate
those with the old Sun MMU we see:

	LEVEL	Sun MMU EQUIV	INDEX WITH
	-----------------------------------------------
	Level 0:	Context base pointer	Context #
	Level 1:	Region table		VA<31:24>
	Level 2:	Segment table		VA<23:18>
	Level 3:	Page table		VA<17:12>
		page offset		VA<11:0>

At any level the SRMMU can encounter a Page Table Pointer (PTP) or a Page
Table Entry (PTE) which contains the translation, protection, etc.

Depending at which level the PTP is encountered the page size varies; 
a PTE at level 3 maps a 4K page, at level 2 maps a 256K page, at level
1 maps a 16 MB page, and at level 0 maps a 4GB page.

A register called the Context Table Pointer tells the MMU where to find
the first table in the MMU.  TLB misses are serviced by the hardware doing
a 'table walk' to find the translation; if no translation is found, the VM
code is called for service (page fault).

A detailed description of the SRMMU can be found in the SPARC Architecture
Manual version 8, available from SPARC International.

Sun is using the SRMMU in the SS600MP family and in SS10.  Machines using
the SRMMU at Sun are all in the Sun-4m family, which is a system architecture
utilizing multiple processors, SRMMU, and other new features.

The SRMMU is also used by other SPARC vendors in their products; some
are shipping today.

chas/
#include <std.disclaimer>: speaking for myself, not my employer