Quoting Will Deacon (2020-10-21 14:13:26)
On Wed, Oct 21, 2020 at 09:12:02AM -0700, Stephen Boyd wrote:
My read of the spec was that the intent is to remove the call at some point and have the removal of the call mean that it isn't vulnerable.
No, the CSV2 field in whichever ID register is for that. We check that in spectre_v2_get_cpu_hw_mitigation_state().
Alright, makes sense!
Because NOT_SUPPORTED per the spec means "not needed", "maybe needed", or "firmware doesn't know". Aha maybe they wanted us to make the call on each CPU (i.e. PE) and then if any of them return 0 we should consider it vulnerable and if they return NOT_SUPPORTED we should keep calling for each CPU until we are sure we don't see a 0 and only see a 1 or NOT_SUPPORTED? Looks like a saturating value sort of thing, across CPUs that we care/know about.
The mitigation state is always per-cpu because of big/little systems, there just isn't a short-cut for the firmware to say "all CPUs are unaffected" like there is for SMCCC_ARCH_WORKAROUND_2 with its "NOT_REQUIRED" return code.
Ok. Can/should kvm be emulating the CSV2 bit that the guest sees? Just wondering why I'm falling into this (ghost) trap in the first place.