Re: [PATCH v9 02/10] x86/bhi: Make clear_bhb_loop() effective on newer CPUs

[Jon Kohler]

> On Apr 7, 2026, at 11:46 AM, Jim Mattson <jmattson@xxxxxxxxxx> wrote:
> 
> On Tue, Apr 7, 2026 at 9:40 AM Pawan Gupta
> <pawan.kumar.gupta@xxxxxxxxxxxxxxx> wrote:
>> 
>> On Mon, Apr 06, 2026 at 07:23:25AM -0700, Jim Mattson wrote:
>>> Yes, but the guest needs a way to determine whether the hypervisor
>>> will do what's necessary to make the short sequence effective. And, in
>>> particular, no KVM hypervisor today is prepared to do that.
>>> 
>>> When running under a hypervisor, without BHI_CTRL and without any
>>> evidence to the contrary, the guest must assume that the longer
>>> sequence is necessary. At the very least, we need a CPUID or MSR bit
>>> that says, "the short BHB clearing sequence is adequate for this
>>> vCPU."
>> 
>> After discussing this internally, the consensus is that the best path
>> forward is to add virtual SPEC_CTRL support to KVM, which also aligns with
>> Intel's guidance. In the long term, virtual SPEC_CTRL can benefit future
>> mitigations as well. As with many other mitigations (e.g. microcode), the
>> guest would rely on the host to enforce the appropriate protections.

Would we have to wait for virtual SPEC_CTRL to get this optimization?

Or would that be a future enhancement to make this more prescriptive?
> 
> I don't think it's reasonable for the guest to rely on a future
> implementation to enforce the appropriate protections.
> 
> This is already a problem today. If a guest sees that BHI_CTRL is
> unavailable, it will deploy the short BHB clearing sequence and
> declare that the vulnerability is mitigated. That isn't true if the
> guest is running on Alder Lake or newer.