On Mon, Nov 11, 2019 at 04:07:39PM +0000, Steven Price wrote:
> On 11/11/2019 15:42, Marc Zyngier wrote:
> >> +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.
>
> > 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.
> > - 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.
>
> > - 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.
> > 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.
_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
