Tims Notes on ARM memory allocation - Revision history

Tim Bird: /* page tables */

2012-05-02T20:15:56Z

‎page tables

Tim Bird: /* page tables */

2012-05-02T20:15:00Z

‎page tables

Tim Bird: /* page tables */ add link to diagram

2012-05-02T20:12:07Z

‎page tables: add link to diagram

Tim Bird: /* paging_init() */

2012-05-02T20:01:06Z

‎paging_init()

Tim Bird: /* paging_init() */ fix formatting

2012-05-02T19:57:17Z

‎paging_init(): fix formatting

Tim Bird: /* paging_init() */

2012-05-02T19:56:54Z

‎paging_init()

Tim Bird at 19:36, 2 May 2012

2012-05-02T19:36:27Z

Tim Bird: add acronmys

2012-05-02T18:30:06Z

add acronmys

Tim Bird: /* page tables */

2012-05-02T18:20:57Z

‎page tables

Tim Bird: /* page tables */

2012-05-02T18:19:23Z

‎page tables

@@ Line 48: / Line 48: @@
 I found the following ARM reference material helpful in trying to understand the page table layout:
-http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0333h/I1029222.html - this is the chapter on  the MMU in the ARM1176JZ-S Technical Reference Manual.  In particular, diagram 6.9 showing ARMv6 section, supersection and page translation, in section 6.11.2 of the manual is very useful.  It is [http://infocenter.arm.com/help/topic/com.arm.doc.ddi0333h/ch06s11s02.html here.]
+http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0333h/Babbhigi.html - this is the chapter on  the MMU in the ARM1176JZ-S Technical Reference Manual.  In particular, diagram 6.9 showing ARMv6 section, supersection and page translation, in section 6.11.2 of the manual is very useful.  It is [http://infocenter.arm.com/help/topic/com.arm.doc.ddi0333h/ch06s11s02.html here.]
 Note that in particular, the second-level page table (PTE) layout is weird.  The ARM hardware supports 1K tables at this level (256 entries of 4bytes each).  However, the Linux kernel needs some bits that are not provided on some hardware (like DIRTY and YOUNG).  These are synthesized by the ARM MMU code via permissions and faulting, effectively making them software-managed.  They have to be stored outside the hardware tables, but still in a place where the kernel can get to them easily.  In order to keep things aligned into units of 4K, the kernel therefore keeps 2 hardware second-level page tables and 2 parallel arrays (totalling 512 entries) on a single page.  When a new second-level page table is created, it is created 512 entries at a time, with the hardware entries at the top of the table, and Linux software entries (synthesized flags and values) at the bottom.

@@ Line 48: / Line 48: @@
 I found the following ARM reference material helpful in trying to understand the page table layout:
-http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0333h/I1029222.html - this is the chapter on  the MMU in the ARM1176JZ-S Technical Reference Manual.  In particular, diagram 6.9 showing ARMv6 section, supersection and page translation, in section 6.11.2 of the manual is very useful.  It is [http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0333h/Bgbfaich.html here.]
+http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0333h/I1029222.html - this is the chapter on  the MMU in the ARM1176JZ-S Technical Reference Manual.  In particular, diagram 6.9 showing ARMv6 section, supersection and page translation, in section 6.11.2 of the manual is very useful.  It is [http://infocenter.arm.com/help/topic/com.arm.doc.ddi0333h/ch06s11s02.html here.]
 Note that in particular, the second-level page table (PTE) layout is weird.  The ARM hardware supports 1K tables at this level (256 entries of 4bytes each).  However, the Linux kernel needs some bits that are not provided on some hardware (like DIRTY and YOUNG).  These are synthesized by the ARM MMU code via permissions and faulting, effectively making them software-managed.  They have to be stored outside the hardware tables, but still in a place where the kernel can get to them easily.  In order to keep things aligned into units of 4K, the kernel therefore keeps 2 hardware second-level page tables and 2 parallel arrays (totalling 512 entries) on a single page.  When a new second-level page table is created, it is created 512 entries at a time, with the hardware entries at the top of the table, and Linux software entries (synthesized flags and values) at the bottom.

@@ Line 48: / Line 48: @@
 I found the following ARM reference material helpful in trying to understand the page table layout:
-http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0333h/I1029222.html - this is the chapter on  the MMU in the ARM1176JZ-S Technical Reference Manual.
+http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0333h/I1029222.html - this is the chapter on  the MMU in the ARM1176JZ-S Technical Reference Manual.  In particular, diagram 6.9 showing ARMv6 section, supersection and page translation, in section 6.11.2 of the manual is very useful.  It is [http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0333h/Bgbfaich.html here.]
 Note that in particular, the second-level page table (PTE) layout is weird.  The ARM hardware supports 1K tables at this level (256 entries of 4bytes each).  However, the Linux kernel needs some bits that are not provided on some hardware (like DIRTY and YOUNG).  These are synthesized by the ARM MMU code via permissions and faulting, effectively making them software-managed.  They have to be stored outside the hardware tables, but still in a place where the kernel can get to them easily.  In order to keep things aligned into units of 4K, the kernel therefore keeps 2 hardware second-level page tables and 2 parallel arrays (totalling 512 entries) on a single page.  When a new second-level page table is created, it is created 512 entries at a time, with the hardware entries at the top of the table, and Linux software entries (synthesized flags and values) at the bottom.

@@ Line 86: / Line 86: @@
 set_pte_ext ('set page table entry extended') takes the following arguments:
 * pte - pointer to pte entry to change (the address of the linux entry - not the 'hardware' entry)
-* value - the value to place in the entry - this is usually created with the macro pfn_pte(x,y), where x has the page frame number (physical address of the page for this mapping), and y represents the protection flags for the page.
+* value - the value to place in the entry - this is usually created with the macro pfn_pte(x,y), where x has the page frame number (physical address of the page for this mapping), and y represents the protection flags for the page.  This should be the 'linux' flags for the page.
 * value2  - the value to place in the "extended" or "extra" entry
 Note that the assembly routine for this, which is cpu-specific, will take the Linux PTE values and derive

@@ Line 66: / Line 66: @@
 A call tree for a regular page table setup is:
-{{{
    start_kernel()
      setup_arch()
@@ Line 83: / Line 83: @@
                  =>  processor.set_pte_ext() - function pointer to cpu-specific routine
                  =>  cpu_armXXX_set_pte_ext() or cpu_procvX_set_pte_ext - cpu-specific-routine
 set_pte_ext ('set page table entry extended') takes the following arguments:

@@ Line 54: / Line 54: @@
 The kernel has a mixture of 1MB mappings and 4KB mappings. This relieves some pressure on the TLB, which
 is used by the CPU to cache virtual-to-physical address translations.
 == Nomenclature ==

← Older revision		Revision as of 18:30, 2 May 2012
Line 54:		Line 54:
	The kernel has a mixture of 1MB mappings and 4KB mappings. This relieves some pressure on the TLB, which		The kernel has a mixture of 1MB mappings and 4KB mappings. This relieves some pressure on the TLB, which
	is used by the CPU to cache virtual-to-physical address translations.		is used by the CPU to cache virtual-to-physical address translations.
		+
		+	== Nomenclature ==
		+	* pgd = page global directory
		+	* pud = page upper directory
		+	* pmd = page middle directory
		+	* pte = page table entry (this is confusion, 'pte' can refer to both the table and an entry in the table)
		+	** ptep = pointer to pte entry
		+	* pfn = page frame number = the base address (no bottom bits) of a physical page address

@@ Line 42: / Line 42: @@
 ARM supports two page table trees simultaneously, using the hardware registers TTBR0 and TTBR1.  A virtual
 address is mapped to a physical address by the CPU depending on settings in TTBRC.  This control register
-has a field which sets a split point in the address space.  Addresses below cutoff value are mapped through the
+has a field which sets a split point in the address space.  Addresses below the cutoff value are mapped through the
 page tables pointed to by TTBR0, and addresses above the cutoff value are mapped through TTBR1.  TTBR0 is
-unique per-process, and is in current->mm.pgd  (That is, current->mm.pgd == TTBR0 for that process).  TTBR1
+unique per-process, and is in current->mm.pgd  (That is, current->mm.pgd == TTBR0 for that process).  That is, when a context switch occurs, the kernel sets TTBR0 to the current->mm.pgd for new process.  TTBR1
-is global for the whole system, and represents the page tables for the kernel.  It is referenced in the global
+is global for the whole system, and represents the page tables for the kernel.  It is referenced in the global kernel variable swapper_pg_dir.  Note that both of these addresses are virtual addresses.  You can find the physical address of the first-level page table by using virt_to_phys() functions on these addresses.
 kernel variable swapper_pg_dir.  Note that both of these addresses are virtual addresses.  You can find the
 physical address of the first-level page table by using virt_to_phys() functions on these addresses.
 I found the following ARM reference material helpful in trying to understand the page table layout:
-http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0333h/I1029222.html - this is the chapter on
+http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0333h/I1029222.html - this is the chapter on  the MMU in the ARM1176JZ-S Technical Reference Manual.
 the MMU in the ARM1176JZ-S Technical Reference Manual.
 Note that in particular, the second-level page table (PTE) layout is weird.  The ARM hardware supports 1K tables at this level (256 entries of 4bytes each).  However, the Linux kernel needs some bits that are not provided on some hardware (like DIRTY and YOUNG).  These are synthesized by the ARM MMU code via permissions and faulting, effectively making them software-managed.  They have to be stored outside the hardware tables, but still in a place where the kernel can get to them easily.  In order to keep things aligned into units of 4K, the kernel therefore keeps 2 hardware second-level page tables and 2 parallel arrays (totalling 512 entries) on a single page.  When a new second-level page table is created, it is created 512 entries at a time, with the hardware entries at the top of the table, and Linux software entries (synthesized flags and values) at the bottom.

← Older revision		Revision as of 18:19, 2 May 2012
Line 52:		Line 52:
	http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0333h/I1029222.html - this is the chapter on		http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0333h/I1029222.html - this is the chapter on
	the MMU in the ARM1176JZ-S Technical Reference Manual.		the MMU in the ARM1176JZ-S Technical Reference Manual.
		+
		+	Note that in particular, the second-level page table (PTE) layout is weird. The ARM hardware supports 1K tables at this level (256 entries of 4bytes each). However, the Linux kernel needs some bits that are not provided on some hardware (like DIRTY and YOUNG). These are synthesized by the ARM MMU code via permissions and faulting, effectively making them software-managed. They have to be stored outside the hardware tables, but still in a place where the kernel can get to them easily. In order to keep things aligned into units of 4K, the kernel therefore keeps 2 hardware second-level page tables and 2 parallel arrays (totalling 512 entries) on a single page. When a new second-level page table is created, it is created 512 entries at a time, with the hardware entries at the top of the table, and Linux software entries (synthesized flags and values) at the bottom.
		+
		+	The kernel has a mixture of 1MB mappings and 4KB mappings. This relieves some pressure on the TLB, which
		+	is used by the CPU to cache virtual-to-physical address translations.