Re: [PATCH v4 04/11] x86/bhi: Make clear_bhb_loop() effective on newer CPUs

[Pawan Gupta <pawan.kumar.gupta@linux.intel.com>]

On Fri, Mar 06, 2026 at 09:05:01PM -0800, Jim Mattson wrote:
> On Fri, Mar 6, 2026 at 6:41 PM Pawan Gupta
> <pawan.kumar.gupta@linux.intel.com> wrote:
> >
> > On Fri, Mar 06, 2026 at 05:10:23PM -0800, Jim Mattson wrote:
> > > On Fri, Mar 6, 2026 at 5:01 PM Pawan Gupta
> > > <pawan.kumar.gupta@linux.intel.com> wrote:
> > > >
> > > > +Chao
> > > >
> > > > On Fri, Mar 06, 2026 at 04:35:49PM -0800, Jim Mattson wrote:
> > > > > > > > > I think we need an explicit CPUID bit that a hypervisor can set to
> > > > > > > > > indicate that the underlying hardware might be SPR or later.
> > > > > > > >
> > > > > > > > Something similar was attempted via virtual-MSRs in the below series:
> > > > > > > >
> > > > > > > > [RFC PATCH v3 09/10] KVM: VMX: Advertise MITI_CTRL_BHB_CLEAR_SEQ_S_SUPPORT
> > > > > > > > https://lore.kernel.org/lkml/20240410143446.797262-10-chao.gao@intel.com/
> > > > > > > >
> > > > > > > > Do you think a rework of this approach would help?
> > > > > > >
> > > > > > > No, I think that whole idea is ill-conceived.  As I said above, the
> > > > > > > hypervisor should just set IA32_SPEC_CTRL.BHI_DIS_S on the guest's
> > > > > > > behalf when BHI_CTRL is not advertised to the guest. I don't see any
> > > > > > > value in predicating this mitigation on guest usage of the short BHB
> > > > > > > clearing sequence. Just do it.
> > > > > >
> > > > > > There are cases where this would be detrimental:
> > > > > >
> > > > > > 1. A guest disabling the mitigation in favor of performance.
> > > > > > 2. A guest deploying the long SW sequence would suffer from two mitigations
> > > > > >    for the same vulnerability.
> > > > >
> > > > > The guest is already getting a performance boost from the newer
> > > > > microarchitecture, so I think this argument is moot.
> > > >
> > > > For a Linux guest this is mostly true. IIRC, there is atleast one major
> > > > non-Linux OS that suffers heavily from BHI_DIS_S.
> > >
> > > Presumably, this guest OS wants to deploy the long sequence (if it may
> > > run on SPR and later) and doesn't want BHI_DIS_S foisted on it. I
> > > don't recall that negotiation being possible with
> > > MSR_VIRTUAL_MITIGATION_CTRL.
> >
> > Patch 4/10 of that series is about BHI_DIS_S negotiation. A guest had to
> > set MITI_CTRL_BHB_CLEAR_SEQ_S_USED to indicate that it isn't aware of the
> > BHI_DIS_S control and is using the short sequence (ya, there is nothing
> > about the long sequence). When KVM sees this bit set, it deploys BHI_DIS_S
> > for that guest.
> >
> > x86/bugs: Use Virtual MSRs to request BHI_DIS_S
> > https://lore.kernel.org/lkml/20240410143446.797262-5-chao.gao@intel.com/
> 
> Ah. I see now. I missed this part of the specification: "Guest OSes
> that are using long or TSX sequences can optionally clear
> BHB_CLEAR_SEQ_S_USED bit in order to communicate this to the VMM."
> 
> Maybe this would be less confusing if BHB_CLEAR_SEQ_S_USED were named
> more clearly. Perhaps something like "SET_BHI_DIS_S_FOR_ME"?

Ya, that would have been clearer.

> Is it reasonable to assume that without the presence of BHI_CTRL, the
> non-Linux OS we've been discussing will (ironically) only use the long
> sequence if the hypervisor advertises BHB_CLEAR_SEQ_S_SUPPORT? That
> is, without BHB_CLEAR_SEQ_S_SUPPORT, does it assume the short sequence
> is adequate?

I don't know. But, it doesn't seem logical to assume short sequence is
adequate when the guest can't ensure that VMM would do BHI_DIS_S for it. It
should be the other way around.