On 18/11/2020 07:12, Michal Orzel wrote:
Hi Julien,
Hi Michal,
On 17.11.2020 18:30, Julien Grall wrote:
Hi Michal,
On 16/11/2020 12:11, Michal Orzel wrote:
On the affected Cortex-A76/Neoverse-N1 cores (r0p0 to r3p0),
if a virtual address for a cacheable mapping of a location is being
accessed by a core while another core is remapping the virtual
address to a new physical page using the recommended break-before-make
sequence, then under very rare circumstances TLBI+DSB completes before
a read using the translation being invalidated has been observed by
other observers. The workaround repeats the TLBI+DSB operation
for all the TLB flush operations on purpose.
Sorry for nitpicking, the commit message should contain enough information for future
reader to understand why this was done "on purpose".
So how about:
"The workaround repeats the TLBI+DSB operation for all the TLB flush operations.
While this is stricly not necessary, we don't want to take any risk.".
I can fix it on commit.
Ok I agree to add this extra clarification.
Please go on and fix it on commit/etc.
Thanks. I have committed now with an extra small change (I hope that's
fine). I decided to not add the extra-clarification in the Kconfig for
two reasons:
1) The description is already pretty long and I wanted to keep it
short. A more user interested with the workaround would likely go and
read the code.
2) There are a risk the description will get desynchronized in the
future. So better to keep the justification close to the implementation.
Cheers,
--
Julien Grall
