aliasing.rst 9.2 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246
  1. ==================================
  2. Memory Attribute Aliasing on IA-64
  3. ==================================
  4. Bjorn Helgaas <bjorn.helgaas@hp.com>
  5. May 4, 2006
  6. Memory Attributes
  7. =================
  8. Itanium supports several attributes for virtual memory references.
  9. The attribute is part of the virtual translation, i.e., it is
  10. contained in the TLB entry. The ones of most interest to the Linux
  11. kernel are:
  12. == ======================
  13. WB Write-back (cacheable)
  14. UC Uncacheable
  15. WC Write-coalescing
  16. == ======================
  17. System memory typically uses the WB attribute. The UC attribute is
  18. used for memory-mapped I/O devices. The WC attribute is uncacheable
  19. like UC is, but writes may be delayed and combined to increase
  20. performance for things like frame buffers.
  21. The Itanium architecture requires that we avoid accessing the same
  22. page with both a cacheable mapping and an uncacheable mapping[1].
  23. The design of the chipset determines which attributes are supported
  24. on which regions of the address space. For example, some chipsets
  25. support either WB or UC access to main memory, while others support
  26. only WB access.
  27. Memory Map
  28. ==========
  29. Platform firmware describes the physical memory map and the
  30. supported attributes for each region. At boot-time, the kernel uses
  31. the EFI GetMemoryMap() interface. ACPI can also describe memory
  32. devices and the attributes they support, but Linux/ia64 currently
  33. doesn't use this information.
  34. The kernel uses the efi_memmap table returned from GetMemoryMap() to
  35. learn the attributes supported by each region of physical address
  36. space. Unfortunately, this table does not completely describe the
  37. address space because some machines omit some or all of the MMIO
  38. regions from the map.
  39. The kernel maintains another table, kern_memmap, which describes the
  40. memory Linux is actually using and the attribute for each region.
  41. This contains only system memory; it does not contain MMIO space.
  42. The kern_memmap table typically contains only a subset of the system
  43. memory described by the efi_memmap. Linux/ia64 can't use all memory
  44. in the system because of constraints imposed by the identity mapping
  45. scheme.
  46. The efi_memmap table is preserved unmodified because the original
  47. boot-time information is required for kexec.
  48. Kernel Identify Mappings
  49. ========================
  50. Linux/ia64 identity mappings are done with large pages, currently
  51. either 16MB or 64MB, referred to as "granules." Cacheable mappings
  52. are speculative[2], so the processor can read any location in the
  53. page at any time, independent of the programmer's intentions. This
  54. means that to avoid attribute aliasing, Linux can create a cacheable
  55. identity mapping only when the entire granule supports cacheable
  56. access.
  57. Therefore, kern_memmap contains only full granule-sized regions that
  58. can referenced safely by an identity mapping.
  59. Uncacheable mappings are not speculative, so the processor will
  60. generate UC accesses only to locations explicitly referenced by
  61. software. This allows UC identity mappings to cover granules that
  62. are only partially populated, or populated with a combination of UC
  63. and WB regions.
  64. User Mappings
  65. =============
  66. User mappings are typically done with 16K or 64K pages. The smaller
  67. page size allows more flexibility because only 16K or 64K has to be
  68. homogeneous with respect to memory attributes.
  69. Potential Attribute Aliasing Cases
  70. ==================================
  71. There are several ways the kernel creates new mappings:
  72. mmap of /dev/mem
  73. ----------------
  74. This uses remap_pfn_range(), which creates user mappings. These
  75. mappings may be either WB or UC. If the region being mapped
  76. happens to be in kern_memmap, meaning that it may also be mapped
  77. by a kernel identity mapping, the user mapping must use the same
  78. attribute as the kernel mapping.
  79. If the region is not in kern_memmap, the user mapping should use
  80. an attribute reported as being supported in the EFI memory map.
  81. Since the EFI memory map does not describe MMIO on some
  82. machines, this should use an uncacheable mapping as a fallback.
  83. mmap of /sys/class/pci_bus/.../legacy_mem
  84. -----------------------------------------
  85. This is very similar to mmap of /dev/mem, except that legacy_mem
  86. only allows mmap of the one megabyte "legacy MMIO" area for a
  87. specific PCI bus. Typically this is the first megabyte of
  88. physical address space, but it may be different on machines with
  89. several VGA devices.
  90. "X" uses this to access VGA frame buffers. Using legacy_mem
  91. rather than /dev/mem allows multiple instances of X to talk to
  92. different VGA cards.
  93. The /dev/mem mmap constraints apply.
  94. mmap of /proc/bus/pci/.../??.?
  95. ------------------------------
  96. This is an MMIO mmap of PCI functions, which additionally may or
  97. may not be requested as using the WC attribute.
  98. If WC is requested, and the region in kern_memmap is either WC
  99. or UC, and the EFI memory map designates the region as WC, then
  100. the WC mapping is allowed.
  101. Otherwise, the user mapping must use the same attribute as the
  102. kernel mapping.
  103. read/write of /dev/mem
  104. ----------------------
  105. This uses copy_from_user(), which implicitly uses a kernel
  106. identity mapping. This is obviously safe for things in
  107. kern_memmap.
  108. There may be corner cases of things that are not in kern_memmap,
  109. but could be accessed this way. For example, registers in MMIO
  110. space are not in kern_memmap, but could be accessed with a UC
  111. mapping. This would not cause attribute aliasing. But
  112. registers typically can be accessed only with four-byte or
  113. eight-byte accesses, and the copy_from_user() path doesn't allow
  114. any control over the access size, so this would be dangerous.
  115. ioremap()
  116. ---------
  117. This returns a mapping for use inside the kernel.
  118. If the region is in kern_memmap, we should use the attribute
  119. specified there.
  120. If the EFI memory map reports that the entire granule supports
  121. WB, we should use that (granules that are partially reserved
  122. or occupied by firmware do not appear in kern_memmap).
  123. If the granule contains non-WB memory, but we can cover the
  124. region safely with kernel page table mappings, we can use
  125. ioremap_page_range() as most other architectures do.
  126. Failing all of the above, we have to fall back to a UC mapping.
  127. Past Problem Cases
  128. ==================
  129. mmap of various MMIO regions from /dev/mem by "X" on Intel platforms
  130. --------------------------------------------------------------------
  131. The EFI memory map may not report these MMIO regions.
  132. These must be allowed so that X will work. This means that
  133. when the EFI memory map is incomplete, every /dev/mem mmap must
  134. succeed. It may create either WB or UC user mappings, depending
  135. on whether the region is in kern_memmap or the EFI memory map.
  136. mmap of 0x0-0x9FFFF /dev/mem by "hwinfo" on HP sx1000 with VGA enabled
  137. ----------------------------------------------------------------------
  138. The EFI memory map reports the following attributes:
  139. =============== ======= ==================
  140. 0x00000-0x9FFFF WB only
  141. 0xA0000-0xBFFFF UC only (VGA frame buffer)
  142. 0xC0000-0xFFFFF WB only
  143. =============== ======= ==================
  144. This mmap is done with user pages, not kernel identity mappings,
  145. so it is safe to use WB mappings.
  146. The kernel VGA driver may ioremap the VGA frame buffer at 0xA0000,
  147. which uses a granule-sized UC mapping. This granule will cover some
  148. WB-only memory, but since UC is non-speculative, the processor will
  149. never generate an uncacheable reference to the WB-only areas unless
  150. the driver explicitly touches them.
  151. mmap of 0x0-0xFFFFF legacy_mem by "X"
  152. -------------------------------------
  153. If the EFI memory map reports that the entire range supports the
  154. same attributes, we can allow the mmap (and we will prefer WB if
  155. supported, as is the case with HP sx[12]000 machines with VGA
  156. disabled).
  157. If EFI reports the range as partly WB and partly UC (as on sx[12]000
  158. machines with VGA enabled), we must fail the mmap because there's no
  159. safe attribute to use.
  160. If EFI reports some of the range but not all (as on Intel firmware
  161. that doesn't report the VGA frame buffer at all), we should fail the
  162. mmap and force the user to map just the specific region of interest.
  163. mmap of 0xA0000-0xBFFFF legacy_mem by "X" on HP sx1000 with VGA disabled
  164. ------------------------------------------------------------------------
  165. The EFI memory map reports the following attributes::
  166. 0x00000-0xFFFFF WB only (no VGA MMIO hole)
  167. This is a special case of the previous case, and the mmap should
  168. fail for the same reason as above.
  169. read of /sys/devices/.../rom
  170. ----------------------------
  171. For VGA devices, this may cause an ioremap() of 0xC0000. This
  172. used to be done with a UC mapping, because the VGA frame buffer
  173. at 0xA0000 prevents use of a WB granule. The UC mapping causes
  174. an MCA on HP sx[12]000 chipsets.
  175. We should use WB page table mappings to avoid covering the VGA
  176. frame buffer.
  177. Notes
  178. =====
  179. [1] SDM rev 2.2, vol 2, sec 4.4.1.
  180. [2] SDM rev 2.2, vol 2, sec 4.4.6.