Viewing page tables and some other questions regarding the MMU

Leo Barnes barnes.leo at gmail.com
Tue Apr 6 17:10:46 EDT 2010


On Tue, Apr 6, 2010 at 7:36 PM, Russell King - ARM Linux
<linux at arm.linux.org.uk> wrote:
> On Tue, Apr 06, 2010 at 06:59:01PM +0200, Leo Barnes wrote:
>> (As a side note, the reason I am investigating this is because I read
>> somewhere in an ARM reference manual that having multiple maps to the
>> same physical region with differing memory attributes is illegal, but
>> ioremap_cached obviously manages it somehow.)
>
> ioremap_cached doesn't "manage it" - it doesn't prevent setting up
> illegal conditions.  That's the responsibility of the programmer to
> ensure that the architecture restrictions aren't violated.
>
> So, the kernel will allow you to create a strongly ordered mapping
> and a cached mapping of the same physical space without complaint;
> if this is not permitted by the architecture, then you must not ask
> the kernel to create this illegal condition.
>

Ah, so ioremap_cached actually does create a second mapping? How come
it works at all? Both mappings that I tested gave the exact same page
table entry (physical base address 0x4000000, non-shared device
memory, non-cached, non-buffered) which is what I would have expected
since anything else would be illegal. But when I actually measure the
byte read speed, the remapped virtual address is definitely cached
while the original virtual address is not. Am I missing something
fundamental? I just can't see how it works since nothing seems to
differ in the page table.

(Should I reply both to the previous sender and the list btw? Couldn't
find anything about this in the list FAQ, I know it is praxis on some
lists not to do it.)

Best regards,
//Leo



More information about the linux-arm mailing list