We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
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.
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.