On 11/04/2024 2:32 pm, Alexandre Chartre wrote: > > On 4/11/24 15:22, Paolo Bonzini wrote: >> On Thu, Apr 11, 2024 at 11:34 AM Alexandre Chartre >> <alexandre.chartre@xxxxxxxxxx> wrote: >>> >>> 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? >>> >>> 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? >> >> The (Linux or otherwise) guest will make its own determinations as to >> whether BHI mitigations are necessary. If the guest uses eIBRS, it >> will run with mitigations. If you hide bit 1 of >> MSR_IA32_ARCH_CAPABILITIES from the guest, it may decide to disable >> it. But if the guest decides to use eIBRS, I think it should use >> mitigations even if the host doesn't. > > The problem is not on servers which have eIBRS, but on servers which > don't. > > If there is no eIBRS on the server, then the guest doesn't know if > there is > effectively no eIBRS on the server or if eIBRS is hidden by the > virtualization > so it applies the BHI mitigation even when that's not needed (i.e. > when eIBRS > is effectively not present the server). > >> It's a different story if the host isn't susceptible altogether. The >> ARCH_CAP_BHI_NO bit *can* be set if the processor doesn't have the bug >> at all, which would be true if cpu_matches(cpu_vuln_whitelist, >> NO_BHI). I would apply a patch to do that. >> > > Right. I have just suggested to enumerate cpus which have eIBRS with > NO_BHI, > but we need would that precise list of cpus. Intel stated that there are no current CPUs for which NO_BHI would be true. What I take this to mean is "no CPUs analysing backwards as far as Intel cared to go". ~Andrew
