Message ID | 20181123184107.39334-1-marc.zyngier@arm.com (mailing list archive) |
---|---|
Headers | show |
Series | Workaround for Cortex-A76 erratum 1165522 | expand |
Hi Marc, On Fri, Nov 23, 2018 at 06:40:59PM +0000, Marc Zyngier wrote: > Early Cortex-A76 suffer from an erratum that can result in invalid > TLBs when the CPU speculatively executes an AT instruction in the > middle of a guest world switch, while the guest virtual memory > configuration is in an inconsistent state. > > We handle this issue by mandating the use of VHE and making sure that > the guest context is fully installed before switching HCR_EL2.TGE to > zero. This ensures that a speculated AT instruction is either executed > on the host context (TGE set) or the guest context (TGE clear), and > that there is no intermediate state. > > There is some additional complexity in the TLB invalidation code, > where we most make sure that a speculated AT instruction cannot mess > the stage-1 TLBs. With James' ISB comments addressed, this looks pretty good to me. What's your plan for merging it? It's definitely going to conflict with the arm64 patch queue and last time that happened Paolo got irritated with us. Will
Hi Will, On Mon, 03 Dec 2018 19:22:43 +0000, Will Deacon <will.deacon@arm.com> wrote: > > Hi Marc, > > On Fri, Nov 23, 2018 at 06:40:59PM +0000, Marc Zyngier wrote: > > Early Cortex-A76 suffer from an erratum that can result in invalid > > TLBs when the CPU speculatively executes an AT instruction in the > > middle of a guest world switch, while the guest virtual memory > > configuration is in an inconsistent state. > > > > We handle this issue by mandating the use of VHE and making sure that > > the guest context is fully installed before switching HCR_EL2.TGE to > > zero. This ensures that a speculated AT instruction is either executed > > on the host context (TGE set) or the guest context (TGE clear), and > > that there is no intermediate state. > > > > There is some additional complexity in the TLB invalidation code, > > where we most make sure that a speculated AT instruction cannot mess > > the stage-1 TLBs. > > With James' ISB comments addressed, this looks pretty good to me. What's > your plan for merging it? It's definitely going to conflict with the > arm64 patch queue and last time that happened Paolo got irritated with us. I'm pretty happy for the whole thing to go via the arm64 tree if you're happy to take it directly. I'll respin the series to address James comments shortly. Thanks, M.