On 17/04/2020 17:41, Will Deacon wrote:
On Fri, Apr 03, 2020 at 01:57:26PM +0100, Andrew Scull wrote:
On Fri, Mar 27, 2020 at 02:59:47PM +0000, Steven Price wrote:
I proposed something similar a while ago[1], but Marc was concerned about
the microarch detail[2] and hence I split the workaround into VHE/non-VHE.
That said I'm not saying this is necessarily wrong, just that we'd need some
more information on whether the non-VHE workaround is suitable for the CPUs
we're currently forcing VHE on.
We noticed that both the nVHE and VHE workarounds share the same
assumption that the EPDx bits are not being cached in the TLB.
`__tlb_switch_to_guest_vhe` and `__tlb_switch_to_guest_nvhe` are both
setting EPDx as part of the workaround. However, neither handles the
possibility of a speculative AT being able to make use of a cached EPD=0
value in the TLB in order to allocate bad TLB entries.
If this is correct, the microarch concern appears to have been solved
already. Otherwise, or if we are unsure, we should go ahead and add the
TLB flushes to keep this safe.
I think Andrew's right here. Can we go ahead with the original approach of
combining the workarounds, or is there something we've missed?
As far as I know it is safe to combine the workarounds: I did post my
own patch earlier. But I don't have the deep understanding of the
microarch - so I accepted Marc's concerns and dropped that, and was
simply linking up the discussions.
The assumption before was that booting a VHE capable system without VHE
wasn't useful, so there wasn't a pressing need to unify the workarounds.
And therefore the easiest option for me was to keep the workarounds
separate. Since there is apparently a desire to do such a thing then
unifying the workarounds seems reasonable.
Steve
_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
