Re: [PATCH 1/2] KVM: VMX: Drop obsolete branch hint prefixes from inline asm

[Sean Christopherson <seanjc@google.com>]

On Wed, Feb 11, 2026, Andrew Cooper wrote:
> On 11/02/2026 3:44 pm, Sean Christopherson wrote:
> > On Wed, Feb 11, 2026, Andrew Cooper wrote:
> >> On 11/02/2026 1:43 pm, David Laight wrote:
> >>> On Wed, 11 Feb 2026 10:57:31 +0000
> >>> Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> >>>
> >>>>> Remove explicit branch hint prefixes (.byte 0x2e / 0x3e) from VMX
> >>>>> inline assembly sequences.
> >>>>>
> >>>>> These prefixes (CS/DS segment overrides used as branch hints on
> >>>>> very old x86 CPUs) have been ignored by modern processors for a
> >>>>> long time. Keeping them provides no measurable benefit and only
> >>>>> enlarges the generated code.  
> >>>> It's actually worse than this.
> >>>>
> >>>> The branch-taken hint has new meaning in Lion Cove cores and later,
> >>>> along with a warning saying "performance penalty for misuse".
> >>>>
> >>>> i.e. "only insert this prefix after profiling".
> >>> Don't they really have much the same meaning as before?
> >> Architecturally yes, microarchitecturally very much not.
> >>
> >> For a branch known to the predictor, there is no effect.  If a branch
> >> unknown to the predictor gets decoded, it triggers a frontend flush and
> >> resteer.
> >>
> >> It is only useful for programs large enough to exceed the working set of
> >> the conditional predictor, and for which certain branches are known to
> >> be ~always taken.
> >>
> >> Putting the prefix on a branch that isn't ~always taken is worse than
> >> not having the prefix in the first place, hence the warning.
> > These branches indeed ~always follow the hinted path (not taken in this case).

Doh, forgot the !CC_HAS_ASM_GOTO_OUTPUT case uses a branch-taken hint.

> > So it sounds like this definitely isn't stable@ material, and maybe even begs
> > the question if dropping the hints is a net positive?
> 
> The new behaviour only exists for hint-taken. Because it only has any
> effect for a branch unknown to the predictor, the behaviour without this
> hint would be as if it were a larger basic block.
> 
> hint-not-takens have no behaviour since the Pentium 4 that I'm aware of.
> 
> This change is almost certainly marginal at best.  It's not as if
> VMREAD/VMWRITE lead to good code gen even at the best of times.

Yeah, but adding in them in the first place was even more marginal (I added the
hints as much for documentation purposes as anything else).  Absent proof that
having the hints is a net positive, I'm inclined to trust the compiler folks on
what is/isn't optimal, and drop them.