VxWorks Reference Manual : Libraries

mmuPro32Lib

NAME

mmuPro32Lib - MMU library for PentiumPro/II

ROUTINES

mmuPro32LibInit( ) - initialize module

DESCRIPTION

mmuPro32Lib.c provides the architecture dependent routines that directly control the memory management unit. It provides 10 routines that are called by the higher level architecture independent routines in vmLib.c:

 mmuLibInit( ) - initialize module
 mmuTransTblCreate( ) - create a new translation table
 mmuTransTblDelete( ) - delete a translation table.
 mmuEnable( ) - turn MMU on or off
 mmuStateSet( ) - set state of virtual memory page
 mmuStateGet( ) - get state of virtual memory page
 mmuPageMap( ) - map physical memory page to virtual memory page
 mmuGlobalPageMap( ) - map physical memory page to global virtual memory page
 mmuTranslate( ) - translate a virtual address to a physical address
 mmuCurrentSet( ) - change active translation table

Applications using the MMU will never call these routines directly; the visible interface is supported in vmLib.c.

mmuLib supports the creation and maintenance of multiple translation tables, one of which is the active translation table when the MMU is enabled. Note that VxWorks does not include a translation table as part of the task context; individual tasks do not reside in private virtual memory. However, we include the facilities to create multiple translation tables so that the user may create "private" virtual memory contexts and switch them in an application specific manner. New translation tables are created with a call to mmuTransTblCreate( ), and installed as the active translation table with mmuCurrentSet( ). Translation tables are modified and potentially augmented with calls to mmuPageMap( ) and mmuStateSet( ). The state of portions of the translation table can be read with calls to mmuStateGet( ) and mmuTranslate( ).

The traditional VxWorks architecture and design philosophy requires that all objects and operating systems resources be visible and accessible to all agents (tasks, isrs, watchdog timers, etc) in the system. This has traditionally been insured by the fact that all objects and data structures reside in physical memory; thus, a data structure created by one agent may be accessed by any other agent using the same pointer (object identifiers in VxWorks are often pointers to data structures.) This creates a potential problem if you have multiple virtual memory contexts. For example, if a semaphore is created in one virtual memory context, you must guarantee that that semaphore will be visible in all virtual memory contexts if the semaphore is to be accessed at interrupt level, when a virtual memory context other than the one in which it was created may be active. Another example is that code loaded using the incremental loader from the shell must be accessible in all virtual memory contexts, since code is shared by all agents in the system.

This problem is resolved by maintaining a global "transparent" mapping of virtual to physical memory for all the contiguous segments of physical memory (on board memory, i/o space, sections of vme space, etc) that is shared by all translation tables; all available physical memory appears at the same address in virtual memory in all virtual memory contexts. This technique provides an environment that allows resources that rely on a globally accessible physical address to run without modification in a system with multiple virtual memory contexts.

An additional requirement is that modifications made to the state of global virtual memory in one translation table appear in all translation tables. For example, memory containing the text segment is made read only (to avoid accidental corruption) by setting the appropriate writable bits in the translation table entries corresponding to the virtual memory containing the text segment. This state information must be shared by all virtual memory contexts, so that no matter what translation table is active, the text segment is protected from corruption. The mechanism that implements this feature is architecture dependent, but usually entails building a section of a translation table that corresponds to the global memory, that is shared by all other translation tables. Thus, when changes to the state of the global memory are made in one translation table, the changes are reflected in all other translation tables.

mmuLib provides a separate call for constructing global virtual memory - mmuGlobalPageMap( ) - which creates translation table entries that are shared by all translation tables. Initialization code in usrConfig makes calls to vmGlobalMap( ) (which in turn calls mmuGlobalPageMap( )) to set up global transparent virtual memory for all available physical memory. All calls made to mmuGlobaPageMap( ) must occur before any virtual memory contexts are created; changes made to global virtual memory after virtual memory contexts are created are not guaranteed to be reflected in all virtual memory contexts.

Most MMU architectures will dedicate some fixed amount of virtual memory to a minimal section of the translation table (a "segment", or "block"). This creates a problem in that the user may map a small section of virtual memory into the global translation tables, and then attempt to use the virtual memory after this section as private virtual memory. The problem is that the translation table entries for this virtual memory are contained in the global translation tables, and are thus shared by all translation tables. This condition is detected by vmMap, and an error is returned, thus, the lower level routines in mmuPro32Lib.c (mmuPageMap( ), mmuGlobalPageMap( )) need not perform any error checking.

A global variable mmuPageBlockSize should be defined which is equal to the minimum virtual segment size. mmuLib must provide a routine mmuGlobalInfoGet( ), which returns a pointer to the globalPageBlock[] array. This provides the user with enough information to be able to allocate virtual memory space that does not conflict with the global memory space.

This module supports the PentiumPro/II MMU:

                            PDBR
                             |
                             |
            -------------------------------------
 top level  |pde  |pde  |pde  |pde  |pde  |pde  | ... 
            -------------------------------------
               |     |     |     |     |     |    
               |     |     |     |     |     |    
      ----------     |     v     v     v     v
      |         ------    NULL  NULL  NULL  NULL
      |         |
      v         v
     ----     ----   
l   |pte |   |pte |
o    ----     ----
w   |pte |   |pte |     
e    ----     ----
r   |pte |   |pte |
l    ----     ----
e   |pte |   |pte |
v    ----     ----
e     .         .
l     .         .
      .         .

where the top level consists of an array of pointers (Page Directory Entry) held within a single 4k page. These point to arrays of Page Table Entry arrays in the lower level. Each of these lower level arrays is also held within a single 4k page, and describes a virtual space of 4 MB (each Page Table Entry is 4 bytes, so we get 1000 of these in each array, and each Page Table Entry maps a 4KB page - thus 1000 * 4096 = 4MB.)

To implement global virtual memory, a separate translation table called mmuGlobalTransTbl is created when the module is initialized. Calls to mmuGlobalPageMap will augment and modify this translation table. When new translation tables are created, memory for the top level array of sftd's is allocated and initialized by duplicating the pointers in mmuGlobalTransTbl's top level sftd array. Thus, the new translation table will use the global translation table's state information for portions of virtual memory that are defined as global. Here's a picture to illustrate:

                 GLOBAL TRANS TBL                     NEW TRANS TBL

                       PDBR                                PDBR
                        |                                   |
                        |                                   |
            -------------------------           -------------------------
 top level  |pde  |pde  | NULL| NULL|           |pde  |pde  | NULL| NULL|
            -------------------------           -------------------------
               |     |     |     |                 |     |     |     |   
               |     |     |     |                 |     |     |     |  
      ----------     |     v     v        ----------     |     v     v
      |         ------    NULL  NULL      |              |    NULL  NULL
      |         |                         |              |
      o------------------------------------              |
      |         |                                        |
      |         o-----------------------------------------
      |         |
      v         v
     ----     ----   
l   |pte |   |pte |
o    ----     ----
w   |pte |   |pte |     
e    ----     ----
r   |pte |   |pte |
l    ----     ----
e   |pte |   |pte |
v    ----     ----
e     .         .
l     .         .
      .         .
Note that with this scheme, the global memory granularity is 4MB. Each time you map a section of global virtual memory, you dedicate at least 4MB of the virtual space to global virtual memory that will be shared by all virtual memory contexts.

The physical memory that holds these data structures is obtained from the system memory manager via memalign to insure that the memory is page aligned. We want to protect this memory from being corrupted, so we invalidate the descriptors that we set up in the global translation that correspond to the memory containing the translation table data structures. This creates a "chicken and the egg" paradox, in that the only way we can modify these data structures is through virtual memory that is now invalidated, and we can't validate it because the page descriptors for that memory are in invalidated memory (confused yet?) So, you will notice that anywhere that page table descriptors (pte's) are modified, we do so by locking out interrupts, momentarily disabling the MMU, accessing the memory with its physical address, enabling the MMU, and then re-enabling interrupts (see mmuStateSet( ), for example.)

Support for two new page attribute bits are added for PentiumPro's enhanced MMU. They are Global bit (G) and Page-level write-through/back bit (PWT). Global bit indicates a global page when set. When a page is marked global and the page global enable (PGE) bit in register CR4 is set, the page-table or page-directory entry for the page is not invalidated in the TLB when register CR3 is loaded or a task switch occurs. This bit is provided to prevent frequently used pages (such as pages that contain kernel or other operating system or executive code) from being flushed from the TLB. Page-level write-through/back bit (PWT) controls the write-through or write- back caching policy of individual pages or page tables. When the PWT bit is set, write-through caching is enabled for the associated page or page table. When the bit is clear, write-back caching is enabled for the associated page and page table. Following macros are used to describe these attribute bits in the physical memory descriptor table sysPhysMemDesc[] in sysLib.c.

 VM_STATE_WBACK - use write-back cache policy for the page 
 VM_STATE_WBACK_NOT - use write-through cache policy for the page 
 VM_STATE_GLOBAL - set page global bit
 VM_STATE_GLOBAL_NOT - not set page global bit

Support for two page size (4KB and 4MB) are added also. The linear address for 4KB pages is divided into three sections:

 Page directory entry - bits 22 through 31.
 Page table entry - Bits 12 through 21.
 Page offset - Bits  0 through 11.

The linear address for 4MB pages is divided into two sections:

 Page directory entry - Bits 22 through 31.
 Page offset - Bits  0 through 21.

These two page size is configurable by VM_PAGE_SIZE macro in config.h.

SEE ALSO

mmuPro32Lib


Libraries : Routines

mmuPro32LibInit( )

NAME

mmuPro32LibInit( ) - initialize module

SYNOPSIS

STATUS mmuPro32LibInit
    (
    int pageSize /* system pageSize (must be 4KB or 4MB) */
    )

DESCRIPTION

Build a dummy translation table that will hold the page table entries for the global translation table. The MMU remains disabled upon completion.

RETURNS

OK if no error, ERROR otherwise

ERRNO

S_mmuLib_INVALID_PAGE_SIZE

SEE ALSO

mmuPro32Lib