When I read the workaround option 1 and 2 for Erratum 6184 I interpret it as that we must not use more than 4 entries in the TLB1 for execution, since it is these that turns up in the I-L1VSP Cache. Is this correct? I can use more than 4 for data?
Which processor is in question?
This errata concerns a number of processors, in fact every e500v2. In my case it is P1022.
Regards
Toby
The Erratum workaround Option 2 corresponds to the case when more than 4 TLB1 entries could be used.
For my understanding: Why can´t the data and instruction pages be contiguous? Is there a risk of speculative fetch in the data area?
What if the data page is only above the code page. Would that be ok?
Or if we have only 3 pages of instructions, since the L1 TLB cache is fully associative, one speculative fetch of a data would not evict any of the existing 3 pages in the L1VSP?
(It may be a difficult restriction to make the pages non-contiguous)
Regards
Toby
> Is there a risk of speculative fetch in the data area?
Yes.
The execute permissions from fetches are checked from the L1, and fetches can be attempted to (virtually) any address depending on branch prediction and other code flow. If one of these match to a TLB1 page marked as data, it’ll still be brought into the L1, potentially causing a capacity eviction of another translation.
Please consider that the erratum state is very rare, so in the Freescale/NXP Linux SDK workaround option 3 is implemented: