On 11/04/2024 10:33 am, Alexandre Chartre wrote: > > > On 4/11/24 10:43, Andrew Cooper wrote: >> 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". >> > > So you mean we can't set ARCH_CAP_BHI_NO for the guest because we > don't know > if the guest will run the (other) existing mitigations which are > believed to > suffice to mitigate BHI? Correct. Also, when a VM really is migrating between different CPUs, things get far more complicated. > > The problem is that we can end up with a guest running extra BHI > mitigations > while this is not needed. Could we inform the guest that eIBRS is not > available > on the system so a Linux guest doesn't run with extra BHI mitigations? Well, that's why Intel specified some MSRs at 0x5000xxxx. Except I don't know anyone currently interested in implementing them, and I'm still not sure if they work correctly for some of the more complicated migration cases. ~Andrew
