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

Pawan Gupta
2026-03-10T00:53:05Z

On Mon, Mar 09, 2026 at 05:08:09PM -0700, Jim Mattson wrote:
> On Mon, Mar 9, 2026 at 5:00 PM Pawan Gupta
> <pawan.kumar.gupta@linux.intel.com> 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@linux.intel.com> 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?

Not really, virtual MSRs can be exposed to guests with and without the
migration pools.

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

What I meant was without the virtual MSRs, a guest has no way to know
whether it could be in a migration pool that spans the change in BHB size.
It has to assume one way or the other.

When the virtual MSRs are enumerated we can better handle the migration
cases. A guest would set/clear BHB_CLEAR_SEQ_S_USED based on whether it
deploys long or short sequence. And When the guest migrates, a VMM would
update the guest's mitigation under-the-hood based on:

if guest BHB_CLEAR_SEQ_S_USED == 1:
if host.CPUID.BHI_CTRL supported:
Set guest.virtual.SPEC_CTRL[BHI_DIS_S]
else:
Do nothing, short sequence is sufficient
else:
Do nothing, guest indicated that it is not using short sequence