Messages in this thread | | | Date | Wed, 20 Nov 2019 19:18:55 +0000 | From | Will Deacon <> | Subject | Re: [PATCH 0/5] arm64: Add workaround for Cortex-A77 erratum 1542418 |
| |
On Fri, Nov 15, 2019 at 01:14:07AM +0000, Suzuki K Poulose wrote: > On 11/14/2019 04:39 PM, Will Deacon wrote: > > On Thu, Nov 14, 2019 at 02:59:13PM +0000, Suzuki K Poulose wrote: > > > This series adds workaround for Arm erratum 1542418 which affects > > > Cortex-A77 cores (r0p0 - r1p0). Affected cores may execute stale > > > instructions from the L0 macro-op cache violating the > > > prefetch-speculation-protection guaranteed by the architecture. > > > This happens when the when the branch predictor bases its predictions > > > on a branch at this address on the stale history due to ASID or VMID > > > reuse. > > > > Two immediate questions: > > > > 1. Can we disable the L0 MOP cache? > Yes, but it hurts performance. > > > 2. Can we invalidate the branch predictor? If Spectre-v2 taught us > > anything it's that removing those instructions was a mistake! > > The workaround suggested is actually invalidating the branch history > but in a costly way. I am unaware of any. > > Moving on... > > > > Have you reproduced this at top-level? If I recall the > > prefetch-speculation-protection, it's designed to protect against the > > case where you have a direct branch: > > No, see below. > > > > > addr: B foo > > > > and another CPU writes out a new function: > > > > bar: > > insn0 > > ... > > insnN > > > > before doing any necessary maintenance and then patches the original > > branch to: > > > > addr: B bar > > > > The idea is that a concurrently executing CPU could mispredict the original > > branch to point at 'bar', fetch the instructions before they've been written > > out and then confirm the prediction by looking at the newly written branch > > instruction. Even without the prefetch-speculation-protection, that's > > fairly difficult to achieve in practice: you'd need to be doing something > > like reusing memory to hold the instructions so that the initial > > misprediction occurs. > > > > How does A77 stop this from occurring when the ASID is not reallocated (e.g. > > the example above)? Is the MOP cache flushed somehow? > > IIUC, The MOP cache is flushed on I-cache invalidate, thus it is fine.
Hmm, so this is interesting. Does that mean we could do a local I-cache invalidation in check_and_switch_context() at the same as doing the local TLBI after a rollover?
I still don't grok the failure case, though, because assuming A77 has IDC=0, then won't you see the I-cache maintenance from userspace anyway?
Will
| |