The hat layer

Some work can be done at a level independent of the actual MMU hardware to keep track of mapping and virtual-to-physical translation information. A large portion of this is just concerned with defining the operations and necessary supporting structures. In the 4.x kernel, a list of functions was defined and then implemented in machine-specific code files. In Solaris 2, the same approach was taken as with vnodes, vfs structures, and segments; a set of operations was defined for each type of MMU, and the generic hat routines just call the appropriate machine-dependent functions after some setup and error checking.

The functions are fairly consistent across the OS versions. The definitions appear in the include file /usr/include/vm/hat.h , and contain routines like:

• hat_memload() ” Load a given page into the translation hardware.

• hat_fault() ” Try to resolve a fault with the existing translations.

• hat_pagesync() ” Get the hardware information into the page structure (the referenced/modified status) and reset the hardware.

• hat_getkpfnum() ” Return the kernel "page frame number" (the actual physical page number) for a given kernel virtual address.

• hat_unload() ” Unload a mapping from the hardware.

In 4.x, these are the functions that actually do the work. In Solaris 2, these functions will immediately call another routine directly related to the particular hardware on that system. A function such as srmmu_memload() will deal with the intricacies of the SPARC Reference Memory Management Unit.

We're now down pretty close to the hardware. Failures in these functions or in routines that they call are quite possibly due to hardware problems, in part because these functions are some of the most heavily used routines in the kernel. If you see problems at this level, you will at least have a pretty good idea what hardware to look at!