Re: [PATCH v6 1/9] x86/bhi: x86/vmscape: Move LFENCE out of clear_bhb_loop()

[Pawan Gupta]

On Thu, Jan 01, 2026 at 01:51:22PM +0100, Borislav Petkov wrote:
> On Mon, Dec 01, 2025 at 10:18:59PM -0800, Pawan Gupta wrote:
> > In preparation for adding the support for BHB sequence (without LFENCE) on
> > newer CPUs, move the LFENCE to the caller side after clear_bhb_loop() is
> > executed. This allows callers to decide whether they need the LFENCE or
> 
> s/This allows/Allow/

> > not. This does adds a few extra bytes to the call sites, but it obviates
> 
> s/This does adds/This adds/

Ok.

> > diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
> > index ed04a968cc7d0095ab0185b2e3b5beffb7680afd..886f86790b4467347031bc27d3d761d5cc286da1 100644
> > --- a/arch/x86/entry/entry_64.S
> > +++ b/arch/x86/entry/entry_64.S
> > @@ -1528,6 +1528,9 @@ SYM_CODE_END(rewind_stack_and_make_dead)
> >   * refactored in the future if needed. The .skips are for safety, to ensure
> >   * that all RETs are in the second half of a cacheline to mitigate Indirect
> >   * Target Selection, rather than taking the slowpath via its_return_thunk.
> > + *
> > + * Note, callers should use a speculation barrier like LFENCE immediately after
> > + * a call to this function to ensure BHB is cleared before indirect branches.
> >   */
> 
> Comments do get missed. So, I'd call the function clear_bhb_loop_unfenced or
> something to that effect so that it is perfectly clear that !BHI_DIS_S parts
> will need the LFENCE at the end. This way it is in the name and should make
> people think what they're calling. I'd hope...

Sure, renaming this to clear_bhb_loop_nofence() in a separate patch.

Will send v7 after some testing.