Top-level page directory in SPARC: what's its equivalent of x86's CR3 register?

Question

I know that in x86 architecture, I can read CR3 register in kernel context to follow page directory of kernel. CR3 points to the top-level page directory. (And its low bits have some control flags, and a process-context ID if that feature is in use, to avoid invalidating all TLB entries on every CR3 change.)

I'm trying to do the same work from Linux with SPARC architecture. How can I access the kernel's page directory?

What register holds this information in SPARC, if there is one?
Is SPARC's paging mechanism the same as x86?

PS: what about ARM?

Answer 1

The SPARC specification as such does not mandate the use of a MMU nor require a specific implementation of a MMU; it merely defines the interface between CPU and MMU (largely concerned about traps that need to be generated via MMU activity).

That said - and I have to state here that I only know about Sun's / Fujitsu's SPARC CPUs, not about the embedded stuff (LEON and predecessors) - SPARC CPUs as far back as sun4 workstation CPUs of 1990 have had MMUs.

As with many non-mandated SPARC CPU features, control of the MMU happens through what's called Address Space Identifiers (ASIs).
These ASIs are a feature of the SPARC architecture that can best be described as a mix between x86 segmentation and memory mapped registers. Their use changes what an "address" means to a SPARC CPU (that's just like the use of a segment [reg] in x86 changes the meaning of the "address") - except that there's no configurable "descriptor table" behind ASI address ranges, but usually hardware-specific control registers. I.e. they're not "mapped" into the ordinary physical address space, but into alternate address ranges.

First - in sun4, sun4c, sun4d and sun4m architectures (32bit sparcv7), the MMU was called srmmu (SPARC reference MMU) and implemented a two-level hardware table walk. This is deprecated and I don't remember out of my head what the control regs for this were.

When Sun created the sun4u architecture, a hardware-implemented translation table walk was considered both too-high an overhead as well as too memory-intensive; therefore the table-walking MMU implementation was completely yanked in favour of implementing most (but not all) of MMU functionality in software. In particular, the only thing programmable into the hardware are the contents of the TLB, translation lookaside buffer - meaning if a mapping isn't readily cached in the TLB, a MMU miss trap occurs and the trap handler will perform a table lookup, reprogramming the TLB at the end (so that re-issuing the instruction afterwards will succeed). That's where the name, sfmmu (Software MMU) comes from. The MMU is controlled through ASI_MMU, while the actual context register is CPU-specific ...

See, for reference:

• pg. 351ff of the 2007 UltraSPARC architecture reference manual - this lists the ASI numbers involved with MMU control.
• OpenSolaris sourcecode, use of ASI_MMU_CTX.
• OpenSolaris sourcecode, sfmmu_asm.s (beware of eyes bleeding and brain becoming mushy)
• OpenSolaris sourcecode, hat_sfmmu.c
  that's the software-side hash chain / translation table walks; it might have the dubious honor of being the largest sourcefile in the Solaris kernel ...

Re, ARM: I suggest you ask the question again, as a separate post. Over the existance of ARM multiple (both mmu-less and with-mmu) implementations have evolved (there is, for example, the ARMv7 instruction set based Cortex-A8/M3 with/out MMU). MMU specifications by ARM themselves are usually called VMSA (Virtual Memory Systems Architecture) and there are several revisions of it. This posting is already too long to contain more details ;-)

Answer 2

On SPARC TLB-faulting is handled in software, so there is nothing like CR3. You'll have to check the current process data structure to find the required information.

ARM on the other hand uses hardware translation, the MMU is handled as a coprocessor using MRC/MCR for accessing the Translation Table Base Register. See ARMs website for more information: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0056d/BABIDADG.html

Answer 3

sun4 and sun4c architectures (sparcv7-architecture CPUs) used an external "Sun4 MMU", also known as the "PMEG MMU". This was architecturally very different from the later srmmu, below.

sun4m and sun4d architectures (SuperSPARC, HyperSPARC, microSPARC, TurboSPARC CPUs) had an on-chip "SPARC Reference MMU" (srmmu). This was, in turn, also quite different from the later sfmmu (srmmu: hardware table-walk; sfmmu: software table-walk with a pre-walked in-memory 2nd-level TLB cache called the translation storage buffer - "TSB").

sun4u (UltraSPARC-I/II/III/IV series CPUs, SPARC64-GP, SPARC64-V/VI/VII) had an on-chip "Spitfire MMU" (sfmmu), named after the original UltraSPARC-I CPU which was code-named Spitfire.

Note that the original SPARC64-I/-II/-III CPUs from HAL, used an MMU architecture different to all of the above.