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

[Jim Mattson]

On Mon, Mar 9, 2026 at 5:00 PM Pawan Gupta
<pawan.kumar.gupta@xxxxxxxxxxxxxxx> wrote:
>
> On Mon, Mar 09, 2026 at 04:05:55PM -0700, Jim Mattson wrote:
> > On Mon, Mar 9, 2026 at 3:29 PM Pawan Gupta
> > <pawan.kumar.gupta@xxxxxxxxxxxxxxx> wrote:
> > > > 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.
> >
> > Assuming BHI_NO is clear...
> >
> > If the hypervisor offers to enable BHI_DIS_S for you, then the
> > migration pool may contain SPR+, so you need the long sequence if
> > you're going to clear the BHB in software rather than accept the
> > hypervisor's offer.
> > You are saying that if the hypervisor does not offer to enable
> > BHI_DIS_S for you, then you know nothing, so you need the long
> > sequence.
>
> This is all when MSR_VIRTUAL_MITIGATION_* is enumerated by the VMM.
>
> > How would a guest that refuses BHI_DIS_S ever be able to use the short sequence?
>
> Without those MSRs a guest could ignore the migration case, and use the
> short sequence.

Ah. So, a hypervisor only advertises MSR_VIRTUAL_MITIGATION_* when the
migration pool spans the change in BHB size?

Why not just declare that explicitly? This whole mechanism seems to be
an exercise in obfuscation.