As described in ARM ARM (ARMv7), mismatched memory attributes for mapping a physical region would happen when either/all of the memory type, shareability or cacheability of aliases differ
My question is specific to the case when it is only the cacheability that is different across aliases. E.g., consider a physical page @0x80000000 mapped @0xE0000000 and @0xF0000000 with
1) mapping @0xE0000000 is normal memory, inner (L1) + outer (L2) cacheable
2) mapping @0xF0000000 is normal memory, inner (L1) cacheable only
Now, in the system , if there are 2 execution threads (may even be across public, secure modes) using the above virtual addresses to access, share the same physical region but taking care of L2 clean/inv before using 0xF0000000 to access the same region, do you see this falls into UNPREDICTABLE operation due to mismatched attributes?
Thanks.
Sorry for not being clear on my requirement earlier. Basically, I am concerned about:
Does the above scenario of only cacheability mismatch falls into being UNPREDICTABLE - provided software takes care of cache maintenance correctly?
The reasons I am seeking clarification on above are following:
1) I have a Cortex A9 based system (single core) where public & secure worlds coexist. The mappings of DDR on public are inner+outer cacheable, (Thraed1 in example) while the mappings for DDR on secure side are inner cacheable only (Thread2). There is a constraint that I could not use L2 on secure side (though I may get around this by probably using TEX remapping but not sure if CP15DISABLE has a role to play preventing the same) but need to share data across both worlds - as efficiently as possible.
Thus, if the above behavior does not fall into UNPREDICTABLE case and proper cache ops could ensure data correctness _always_, then I could still have proper sharing (leaving out L2).
2) Compare the above scenario with mismatched attributes concerning memory types - one mapping as NORMAL memory while other as DEVICE - that would in any case remain UNPREDICTABLE, right?
3) There is one post in the Linux community where it is mentioned (quoting from http://lwn.net/Articles/409700/):
"multiple mappings of the same physical address region with differing
cache attributes is also unpredictable - you can't guarantee whether
the access will be performed using the cache attributes through the
mapping you're performing the access through."
My understanding of the above statement is (from our example) - using 0xF0000000 to access memory with non-outer cacheable may still lead to the actual access being made to L2 (as if using 0xE0000000). Now, this would indicate the behavior is UNPREDICTABLE but not clear if that indeed could be the case and how.
Continuation with above, I have confirmed that using TEX remapping is not possible in this case and thus I have to live with the above mentioned aliases where one will have L1 & L2 cacheable and other having L1 only attributes.
Since I can't change either of the mappings, only option would be to do explicit flush on both the threads and not caring about performance:
1) Thread1 (using 0xE0000000 - inner + outer cacheable) writes to memory and does L1 flush, L2 clean range
2) Thread2 (using 0xF0000000 - inner cacheable only) reads, writes the same memory and does L1 flush to PoC
3) Thread1 does L2 invalidate range
4) Thread1 reads memory, so on...
Will the above sequence be safe in this case (both threads do these operations exclusively)?
Thanks for clarifications, I have understood that this kind of mapping will lead to UNPREDICTABLE behavior at some time.