On 11/04/2024 8:24 am, Alexandre Chartre wrote: > When a system is not affected by the BHI bug then KVM should > configure guests with BHI_NO to ensure they won't enable any > BHI mitigation. > > Signed-off-by: Alexandre Chartre <alexandre.chartre@xxxxxxxxxx> > --- > arch/x86/kvm/x86.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c > index 984ea2089efc..f43d3c15a6b7 100644 > --- a/arch/x86/kvm/x86.c > +++ b/arch/x86/kvm/x86.c > @@ -1678,6 +1678,9 @@ static u64 kvm_get_arch_capabilities(void) > if (!boot_cpu_has_bug(X86_BUG_GDS) || gds_ucode_mitigated()) > data |= ARCH_CAP_GDS_NO; > > + if (!boot_cpu_has_bug(X86_BUG_BHI)) > + data |= ARCH_CAP_BHI_NO; This isn't true or safe. Linux only sets X86_BUG_BHI on a subset of affected parts. Skylake for example *is* affected by BHI. It's just that existing mitigations are believed to suffice to mitigate BHI too. "you happen to be safe if you're doing something else too" doesn't remotely have the same meaning as "hardware doesn't have a history based predictor". ~Andrew
