On Tue, Jan 04, 2011 at 05:23:37PM +0100, Johan MOSSBERG wrote:
Here's the extracts from the architecture reference manual:
* If the same memory locations are marked as having different
cacheability attributes, for example by the use of aliases in a
virtual to physical address mapping, behavior is UNPREDICTABLE.
A3.5.7 Memory access restrictions
Behavior is UNPREDICTABLE if the same memory location:
* is marked as Shareable Normal and Non-shareable Normal
* is marked as having different memory types (Normal, Device, or
Strongly-ordered)
* is marked as having different cacheability attributes
* is marked as being Shareable Device and Non-shareable Device memory.
Such memory marking contradictions can occur, for example, by the use of
aliases in a virtual to physical address mapping.
Glossary:
UNPREDICTABLE
Means the behavior cannot be relied upon. UNPREDICTABLE behavior must not
represent security holes. UNPREDICTABLE behavior must not halt or hang
the processor, or any parts of the system. UNPREDICTABLE behavior must not
be documented or promoted as having a defined effect.
Given the extract from the architecture reference manual, do you want
to run a system where you can't predict what the behaviour will be if
you have two mappings present, one which is cacheable and one which is
non-cacheable, and you're relying on the non-cacheable mapping to never
return data from the cache?
What if during your testing, it appears to work correctly, but out in
the field, someone's loaded a different application to your setup
resulting in different memory access patterns, causing cache lines to
appear in the non-cacheable mapping, and then the CPU hits them on
subsequent accesses corrupting data...
You can't say that will never happen if you're relying on this
unpredictable behaviour.
--
