On Fri, Apr 14, 2023 at 05:51:43PM +0800, Binbin Wu wrote: > > On 4/14/2023 2:25 PM, Chao Gao wrote: > > Changes since RFC v1: > > * add two kselftests (patch 10-11) > > * set virtual MSRs also on APs [Pawan] > > * enable "virtualize IA32_SPEC_CTRL" for L2 to prevent L2 from changing > > some bits of IA32_SPEC_CTRL (patch 4) > > * other misc cleanup and cosmetic changes > > > > RFC v1: https://lore.kernel.org/lkml/20221210160046.2608762-1-chen.zhang@xxxxxxxxx/ > > > > > > This series introduces "virtualize IA32_SPEC_CTRL" support. Here are > > introduction and use cases of this new feature. > > > > ### Virtualize IA32_SPEC_CTRL > > > > "Virtualize IA32_SPEC_CTRL" [1] is a new VMX feature on Intel CPUs. This feature > > allows VMM to lock some bits of IA32_SPEC_CTRL MSR even when the MSR is > > pass-thru'd to a guest. > > > > > > ### Use cases of "virtualize IA32_SPEC_CTRL" [2] > > > > Software mitigations like Retpoline and software BHB-clearing sequence depend on > > CPU microarchitectures. And guest cannot know exactly the underlying > > microarchitecture. When a guest is migrated between processors of different > > microarchitectures, software mitigations which work perfectly on previous > > microachitecture may be not effective on the new one. To fix the problem, some > > hardware mitigations should be used in conjunction with software mitigations. > > So even the hardware mitigations are enabled, the software mitigations are > still needed, right? Retpoline mitigation is not fully effective when RET can take prediction from an alternate predictor. Newer hardware provides a way to disable this behavior (using RRSBA_DIS_S bit in MSR SPEC_CTRL). eIBRS is the preferred way to mitigate BTI, but for some reason when a guest has deployed retpoline, VMM can make it more effective by deploying the relevant hardware control. That is why the above text says: "... hardware mitigations should be used in conjunction with software mitigations."
