IA32 Paging Scheme Introduction to the Pentium’s support for “virtual” memory

A quick review We’ve learned how to create ‘/proc’ files We wrote a simple device-driver: ‘dram.c’ We displayed a task’s page-directory We looked at Linux’s ‘mem_map[]’ array Now we want to understand the ‘kmap()’ function, used by modules to get a virtual address for any physical page-frame

‘Traditional’ Linux User space Virtual addresses Kernel space NORMAL MEMORY HIGH MEMORY Physical addresses 0x x (896MB) Most of the kernel’s 1GB address-space is directly mapped to physical RAM at all times 1G 3G But mappings to the ‘high memory’ page-frames are, by definition, only temporarily available and are not mapped according to a predictable rule

How ‘mappings’ work There are two aspects to consider: –the Pentium’s address-translation mechanism –the policies Linux applies to CPU capabilities Example of this distinction: –The ‘page-directory’ array is a Pentium object –The ‘mem_map’ array is a Linux data-object

Control Register PAEPAE PSEPSE 45 This register consists of bits that enable various architectural extensions to the standard features of the Pentium processor, including two that affect virtual-to-physical memory mapping. Legend: PSE = Page-Size Extensions (1=enabled, 0=disabled) PAE = Page-Address Extensions (1=enabled, 0=disabled) Recall that we saw our classroom workstations had CR4 = D0

Two-Level Translation Scheme PAGE DIRECTORY CR3 PAGE TABLES PAGE FRAMES

Control Register 3 PWTPWT PCDPCD Page-directory base-address PWT = Page Write-Through (1=yes, 0 = no) PCD = Page Cache-Disable (1 = yes, 0 = no) The ‘page-directory base-address’ field holds the upper 20 address-bits of a physical page-frame that contains the current task’s page-directory entries; the lower 12 address-bits of any page-frame are zeros, of course, so can be used by the processor for other purposes (i.e., PCD [bit 4] and PWT [bit 3]:

Your ‘/proc/cr3’ pseudo-file Recall that you created a kernel module (named ‘cr3.c’) which allows applications to obtain the current value in register CR3 This CR3 value gives the physical address for the current task’s page-directory, if the ‘traditional’ 3G/1G user-kernel mapping is employed (but not with the 4G/4G “patch”) Using ‘fileview’ you saw a page-directory!

Format of a Page-Directory entry PAGE-TABLE BASE ADDRESSPWU PWTPWT PCDPCD A0 PSPS G AVAIL LEGEND P = Present (1=yes, 0=no) W = Writable (1 = yes, 0 = no) U = User (1 = yes, 0 = no) A = Accessed (1 = yes, 0 = no) G = Global (1 = yes, 0 = no) PWT = Page Write-Through (1=yes, 0 = no) PCD = Page Cache-Disable (1 = yes, 0 = no) PS = Page-Size (0=4KB, 1 = 4MB)

Format of a Page-Table entry PAGE-FRAME BASE ADDRESSPWU PWTPWT PCDPCD AD0G AVAIL LEGEND P = Present (1=yes, 0=no) W = Writable (1 = yes, 0 = no) U = User (1 = yes, 0 = no) A = Accessed (1 = yes, 0 = no) D = Dirty (1 = yes, 0 = no) G = Global (1 = yes, 0 = no) PWT = Page Write-Through (1=yes, 0 = no) PCD = Page Cache-Disable (1 = yes, 0 = no)

kernel mappings The ‘kmap()’ function is used by modules to obtain the virtual address for a physical page-frame: void * kmap( struct page * page ); On systems with 1GB of installed memory, the majority of physical page-frames are permanently mapped to kernel addresses, but page-frames in ‘high’ memory can only be ‘temporarily’ mapped into kernel space

Normal page-mapping For a virtual address in kernel space that is below the high-memory start-address, the corresponding physical address can be gotten by a simple subtraction: phys_addr = virt_addr – PAGE_OFFSET Recall: PAGE_OFFSET = 0xC

Mapping ‘high’ memory For addresses in kernel space in the range from 0xF to 0xFFFFFFFF there might be no current mapping to ram So the action of the ‘kmap()’ function must be more complex in these cases (i.e., it’s necessary to create a temporary mapping if it happens one does not already exist)

A limited number of kmaps In kernel 2.6 there is only one page-table that is reserved for ‘kmap()’ to use when temporary mappings into high-memory need to be created This is called the ‘kmap_page_table’ Its page-table entries are forever changing as kernel code calls the functions ‘kmap()’ and ‘kunmap()’

PKMAP_BASE We can watch the ‘kmap_page_table’ as it undergoes these dynamic changes – if we know where to find it in physical memory We can do a ‘page-table walk’ to locate it There are 1024 virtual page-frames used for temporary ‘kmap()’ addresses, starting with the virtual address PKMAP_BASE

In-class exercise #1 Use the ‘init_mm.c’ module to locate the page-directory belonging to the ‘init’ task Use ‘fileview’ to see these directory entries Determine the value of PKMAP_BASE Which directory-entry contains the address of the ‘pkmap_page_table’? (It’s the entry that ‘maps’ virtual-address PKMAP_BASE to a page-frame in physical memory)

In-class exercise #2 Use the result from your ‘page-table walk’ to assign the correct value to ‘zone_base’ in our ‘kmapsnow.cpp’ demo-program Run the ‘kmapsnow’ in one window while you execute some other commands from inside a different window, to view changes in the set of currently active kmaps Log in remotely from an adjacent station