On Sat, Mar 28, 2020 at 11:23:51AM +0000, Marc Zyngier wrote: > On Fri, 27 Mar 2020 18:09:14 +0000 > Will Deacon <will@xxxxxxxxxx> wrote: > > > On Fri, Mar 27, 2020 at 05:52:59PM +0000, Marc Zyngier wrote: > > > On 2020-03-27 17:48, Andrew Scull wrote: > > > > Thanks, Steven. Could we look into the EPD* caching microarch details > > > > Marc was referring to for these A55 and A76 cores? > > > > > > Only the folks that have access to the RTL can tell you, unfortunately. > > > > > > Thankfully, there is a bunch of people on Cc that should be able to ping > > > the relevant teams and report back... > > > > Yup, otherwise I guess we can throw in the TLB invalidation after setting > > the EPDx bits until we have clarity from Arm. We wouldn't need to broadcast > > it, so it might not be too bad on performance. If it is, I suppose we could > > switch to a reserved VMID? > > I'd like to avoid the reserved VMID if at all possible -- we already > have one for the host on nVHE, and I bet your patches are going to > create some interesting havoc^Wchanges in that area, as the host is now > a guest from the mm perspective. It isn't clear either whether a > reserved VMID really solves the problem either, as you could still > end-up with speculative PTWs. Can it be harmful to create conflicting > TLB entries if you never hit them? I think you'd have to ensure that the reserved VMID is only ever used when the EPDx bits are set, which is easy to say but harder to enforce! > But if we bring in TLB invalidation, I wonder whether the problem can > be mitigated solely with just that on the affected CPUs, and what the > impact would be. It seems as though this erratum is quietly cropping up for other CPUs (e.g. A53 and A77) as well, so I'd be inclined to add the local TLBI and then Arm can do the uarch work to disable it if it's worth it. Interestingly, I think you only need the invalidation on the __deactivate_traps_nvhe() path, because the CPU is only permitted to cache those bits when they are 0 (strange but true!). Will _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
