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.
One thing I didn't see mentioned yet: in relevant entry of the secure-world translation tables, is the NS bit set for this shared memory region? i.e. it is mapped as non-secure or as secure?
Since the security state is regarded as part of the physical address, the latter case would mean you don't have inconsistent attributes for the same memory region, since they aren't the same memory region, they just happen to alias in the memory system. From the processor's point of view, it would be like they are separate memory regions with some magic DMA engine behind the scenes copying data between them, and you could treat it exactly like that: after updating one region, take the usual steps to prepare it for outgoing DMA, then in the other security state pretend incoming DMA to the other region has just finished. This way you can benefit from the fact that facilities to correctly manage memory for use with DMA are usually already available.
If on the other hand the memory is mapped as non-secure on the secure side, then why not give the relevant region the same attributes on the public side as on the secure side? That way you don't have to do any cache flushing at all: data can happily stay in L1 cache across the context switch. You could optionally keep the memory outer cacheable most of the time and change to inner-only cacheable before handing it over to secure world (and change it back when it's done with it). This has most of the benefits you seek, but I don't know how expensive it is to change memory attributes on a cortex-A9 and whether you can keep data in L1 while doing so. As a final alternative, if there's any way you can get the same memory region to appear at two different physical addresses then the trick of the previous paragraph can be used again.