aboutsummaryrefslogtreecommitdiffstats
path: root/Documentation/ia64/aliasing.txt
diff options
context:
space:
mode:
authorPaul Mackerras <paulus@samba.org>2007-05-07 23:37:51 -0400
committerPaul Mackerras <paulus@samba.org>2007-05-07 23:37:51 -0400
commit02bbc0f09c90cefdb2837605c96a66c5ce4ba2e1 (patch)
tree04ef573cd4de095c500c9fc3477f4278c0b36300 /Documentation/ia64/aliasing.txt
parent7487a2245b8841c77ba9db406cf99a483b9334e9 (diff)
parent5b94f675f57e4ff16c8fda09088d7480a84dcd91 (diff)
Merge branch 'linux-2.6'
Diffstat (limited to 'Documentation/ia64/aliasing.txt')
-rw-r--r--Documentation/ia64/aliasing.txt71
1 files changed, 37 insertions, 34 deletions
diff --git a/Documentation/ia64/aliasing.txt b/Documentation/ia64/aliasing.txt
index 38f9a52d1820..9a431a7d0f5d 100644
--- a/Documentation/ia64/aliasing.txt
+++ b/Documentation/ia64/aliasing.txt
@@ -112,16 +112,6 @@ POTENTIAL ATTRIBUTE ALIASING CASES
112 112
113 The /dev/mem mmap constraints apply. 113 The /dev/mem mmap constraints apply.
114 114
115 However, since this is for mapping legacy MMIO space, WB access
116 does not make sense. This matters on machines without legacy
117 VGA support: these machines may have WB memory for the entire
118 first megabyte (or even the entire first granule).
119
120 On these machines, we could mmap legacy_mem as WB, which would
121 be safe in terms of attribute aliasing, but X has no way of
122 knowing that it is accessing regular memory, not a frame buffer,
123 so the kernel should fail the mmap rather than doing it with WB.
124
125 read/write of /dev/mem 115 read/write of /dev/mem
126 116
127 This uses copy_from_user(), which implicitly uses a kernel 117 This uses copy_from_user(), which implicitly uses a kernel
@@ -138,14 +128,20 @@ POTENTIAL ATTRIBUTE ALIASING CASES
138 128
139 ioremap() 129 ioremap()
140 130
141 This returns a kernel identity mapping for use inside the 131 This returns a mapping for use inside the kernel.
142 kernel.
143 132
144 If the region is in kern_memmap, we should use the attribute 133 If the region is in kern_memmap, we should use the attribute
145 specified there. Otherwise, if the EFI memory map reports that 134 specified there.
146 the entire granule supports WB, we should use that (granules 135
147 that are partially reserved or occupied by firmware do not appear 136 If the EFI memory map reports that the entire granule supports
148 in kern_memmap). Otherwise, we should use a UC mapping. 137 WB, we should use that (granules that are partially reserved
138 or occupied by firmware do not appear in kern_memmap).
139
140 If the granule contains non-WB memory, but we can cover the
141 region safely with kernel page table mappings, we can use
142 ioremap_page_range() as most other architectures do.
143
144 Failing all of the above, we have to fall back to a UC mapping.
149 145
150PAST PROBLEM CASES 146PAST PROBLEM CASES
151 147
@@ -158,7 +154,7 @@ PAST PROBLEM CASES
158 succeed. It may create either WB or UC user mappings, depending 154 succeed. It may create either WB or UC user mappings, depending
159 on whether the region is in kern_memmap or the EFI memory map. 155 on whether the region is in kern_memmap or the EFI memory map.
160 156
161 mmap of 0x0-0xA0000 /dev/mem by "hwinfo" on HP sx1000 with VGA enabled 157 mmap of 0x0-0x9FFFF /dev/mem by "hwinfo" on HP sx1000 with VGA enabled
162 158
163 See https://bugzilla.novell.com/show_bug.cgi?id=140858. 159 See https://bugzilla.novell.com/show_bug.cgi?id=140858.
164 160
@@ -171,28 +167,25 @@ PAST PROBLEM CASES
171 so it is safe to use WB mappings. 167 so it is safe to use WB mappings.
172 168
173 The kernel VGA driver may ioremap the VGA frame buffer at 0xA0000, 169 The kernel VGA driver may ioremap the VGA frame buffer at 0xA0000,
174 which will use a granule-sized UC mapping covering 0-0xFFFFF. This 170 which uses a granule-sized UC mapping. This granule will cover some
175 granule covers some WB-only memory, but since UC is non-speculative, 171 WB-only memory, but since UC is non-speculative, the processor will
176 the processor will never generate an uncacheable reference to the 172 never generate an uncacheable reference to the WB-only areas unless
177 WB-only areas unless the driver explicitly touches them. 173 the driver explicitly touches them.
178 174
179 mmap of 0x0-0xFFFFF legacy_mem by "X" 175 mmap of 0x0-0xFFFFF legacy_mem by "X"
180 176
181 If the EFI memory map reports this entire range as WB, there 177 If the EFI memory map reports that the entire range supports the
182 is no VGA MMIO hole, and the mmap should fail or be done with 178 same attributes, we can allow the mmap (and we will prefer WB if
183 a WB mapping. 179 supported, as is the case with HP sx[12]000 machines with VGA
180 disabled).
184 181
185 There's no easy way for X to determine whether the 0xA0000-0xBFFFF 182 If EFI reports the range as partly WB and partly UC (as on sx[12]000
186 region is a frame buffer or just memory, so I think it's best to 183 machines with VGA enabled), we must fail the mmap because there's no
187 just fail this mmap request rather than using a WB mapping. As 184 safe attribute to use.
188 far as I know, there's no need to map legacy_mem with WB
189 mappings.
190 185
191 Otherwise, a UC mapping of the entire region is probably safe. 186 If EFI reports some of the range but not all (as on Intel firmware
192 The VGA hole means the region will not be in kern_memmap. The 187 that doesn't report the VGA frame buffer at all), we should fail the
193 HP sx1000 chipset doesn't support UC access to the memory surrounding 188 mmap and force the user to map just the specific region of interest.
194 the VGA hole, but X doesn't need that area anyway and should not
195 reference it.
196 189
197 mmap of 0xA0000-0xBFFFF legacy_mem by "X" on HP sx1000 with VGA disabled 190 mmap of 0xA0000-0xBFFFF legacy_mem by "X" on HP sx1000 with VGA disabled
198 191
@@ -202,6 +195,16 @@ PAST PROBLEM CASES
202 This is a special case of the previous case, and the mmap should 195 This is a special case of the previous case, and the mmap should
203 fail for the same reason as above. 196 fail for the same reason as above.
204 197
198 read of /sys/devices/.../rom
199
200 For VGA devices, this may cause an ioremap() of 0xC0000. This
201 used to be done with a UC mapping, because the VGA frame buffer
202 at 0xA0000 prevents use of a WB granule. The UC mapping causes
203 an MCA on HP sx[12]000 chipsets.
204
205 We should use WB page table mappings to avoid covering the VGA
206 frame buffer.
207
205NOTES 208NOTES
206 209
207 [1] SDM rev 2.2, vol 2, sec 4.4.1. 210 [1] SDM rev 2.2, vol 2, sec 4.4.1.