On Thu, Apr 11, 2024 at 05:20:30PM +0200, Paolo Bonzini wrote: >On Thu, Apr 11, 2024 at 5:13 PM Alexandre Chartre ><alexandre.chartre@xxxxxxxxxx> wrote: >> I think that Andrew's concern is that if there is no eIBRS on the host then >> we do not set X86_BUG_BHI on the host because we know the kernel which is >> running and this kernel has some mitigations (other than the explicit BHI >> mitigations) and these mitigations are enough to prevent BHI. But still >> the cpu is affected by BHI. > >Hmm, then I'm confused. It's what I wrote before: "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" but you said machines without eIBRS are fine. > >If instead they are only fine _with Linux_, then yeah we cannot set >BHI_NO in general. What we can do is define a new bit that is in the >KVM leaves. The new bit is effectively !eIBRS, except that it is >defined in such a way that, in a mixed migration pool, both eIBRS and >the new bit will be 0. This looks a good solution. We can also introduce a new bit indicating the effectiveness of the short BHB-clearing sequence. KVM advertises this bit for all pre-SPR/ADL parts. Only if the bit is 1, guests will use the short BHB-clearing sequence. Otherwise guests should use the long sequence. In a mixed migration pool, the VMM shouldn't expose the bit to guests. > >Paolo > >
