Cortex-A9: Eviction of dirty line from the region marked as Only "Inner Cacheable" from L1 cache - will if be allocated into L2?

Yes, L2 is PL310.

Does this mean the ARCACHEM[3:0]/AWCACHEM[3:0] etc encoding are not honored in the case of evictions from L1, even when data is non-shared?

From PL310 TRM, for Normal non-shared memory:

Table 2-7 Cacheable but do not allocate AXI transactions

Outer non cacheable --

     Read: Not cached in L2, results in L3 access.

     Write: Put in store buffer, write to L3 when store buffer is drained.

Is the above table invalid in case of evictions of the line which had outer non-cacheable attribute?

Thanks.

Sorry - mistake my side - based on what I can see in the manual PL310 assumes that it is an "outer cache" always; I thought it could be configured as inner or outer as a configuration option, but apparently not.

Table 2-4 in the TRM below gives a pretty complete list of cache behaviors for each memory attribute type - does this answer your question?

http://infocenter.arm.com/help/topic/com.arm.doc.ddi0246a/DDI0246A_l2cc_pl310_r0p0_trm.pdf

At this time, my question is, since original attributes for this line were not "outer cacheable", will the line still may be allocated into L2, or will directly be written to L3, always?

Assuming you are using PL310 it does support write allocate, so allocation into the L2 is certainly possible and likely, although not guaranteed. *EDIT* No it's not - see my next reply

Note that in most modern systems the L2 cache is generally treated as an inner cache really;  on the big.LITTLE Cortex cores outer shared is used to imply system level coherency - although this isn't mandated for Cortex-A9.

What if L2 is in exclusive cache mode?

That just means that the same line cannot be in multiple caches concurrently.

HTH,
Pete

This is the same table I am referring to.

Basically, I wanted to confirm that this rule will be followed even on evictions. That is, L1 must store the memory attributes for the region when the line was allocated in L1 and on eviction use the same to propagate to L2.

If the above is correct, then the memory written as inner cacheable, non-outer cacheable, non-shared will never land into L2, right?

Thanks.

If the above is correct, then the memory written as inner cacheable, non-outer cacheable, non-shared will never land into L2, right

Yes, an eviction should be treated like any other write and must honour the page table settings. It looks like outer non-cacheable will never write allocate, but may write into the cache if that line was already present for some reason.

Thanks a lot for confirming.

This fits the observations I had during long tests, still wanted to rule out if this falls into UNPREDICTABLE case.