Re: [PATCH 1/2] arm64: Rename WORKAROUND_1165522 to SPECULATIVE_AT

On Mon, Nov 11, 2019 at 04:07:39PM +0000, Steven Price wrote:

On 11/11/2019 15:42, Marc Zyngier wrote:

quoted

quoted

+config ARM64_WORKAROUND_SPECULATIVE_AT
+    bool
+
 config ARM64_ERRATUM_1165522
     bool "Cortex-A76: Speculative AT instruction using out-of-context
translation regime could cause subsequent request to generate an
incorrect translation"
     default y
+    select ARM64_WORKAROUND_SPECULATIVE_AT

I'd object that ARM64_ERRATUM_1319367 (and its big brother 1319537)
are also related to speculative AT execution, and yet are not covered
by this configuration symbol.

Good point.

quoted

I can see three solutions to this:

- Either you call it SPECULATIVE_AT_VHE and introduce SPECULATIVE_AT_NVHE
  for symmetry

Tempting...

FWIW, this sounds fine to me.

quoted

- Or you make SPECULATIVE_AT cover all the speculative AT errata, which
  may or may not work...

This actually sounds the neatest, but I'm not sure whether there's going
to be any conflicts between VHE/NVHE. I'll prototype this and see how
ugly it is.

quoted

- Or even better, you just ammend the documentation to say that 1165522
  also covers the newly found A55 one (just like we have for A57/A72)

Well Mark Rutland disliked my initial thoughts about just including both
errata in one option like that - hence the refactoring in this patch.
Although of course that's exactly what's happened with 1319367/1319537...

My view on this is that using one erratum config symbol to cover the
workaround for another is more confusing than having a level of
indirection, and I would've preferred the indirection for that case too.
 

quoted

What do you think?

I'll have a go at SPECULATIVE_AT covering both VHE/NVHE - from an
initial look it seems like it should work and it would be neat if it
does. In particular it should avoid the necessity to require VHE when
the erratum is present.

Otherwise I guess SPECULATIVE_AT_{,N}VHE is probably second best.

Both sound good to me.

Thanks for dealing with this!

Mark.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel