Re: [PATCH v3 14/16] x86/fred: Play nice with invoking asm_fred_entry_from_kvm() on non-FRED hardware

[Peter Zijlstra <peterz@infradead.org>]

On Fri, Jul 25, 2025 at 09:54:32PM -0700, Xin Li wrote:
> On 7/14/2025 3:20 AM, Peter Zijlstra wrote:
> >   	call __fred_entry_from_kvm		/* Call the C entry point */
> > -	POP_REGS
> > -	ERETS
> > -1:
> > +
> > +1:	/*
> 
> The symbol "1" is misplaced; it needs to be put after the ERETS
> instruction.

Doh, fixed.

> > +	 * When FRED, use ERETS to potentially clear NMIs, otherwise simply
> > +	 * restore the stack pointer.
> > +	 */
> > +	ALTERNATIVE "nop; nop; mov %rbp, %rsp", \
> 
> Why explicitly add two nops here?

Because the CFI information for all alternative code flows must be the
same. So by playing games with instruction offsets you can have
conflicting CFI inside the alternative.

Specifically, we have:

0:	90        nop
1:	90        nop
2:	48 89 ec  mov %rbp, %rsp


0:	48 83 c4 0c  add $12, %rsp
4:      f2 0f 01 ca  erets

This gets us CFI updates on 0, 2 and 4, without conflicts.


> ALTERNATIVE will still pad three-byte nop after the MOV instruction.
> 
> > +	            __stringify(add $C_PTREGS_SIZE, %rsp; ERETS), \
> > +		    X86_FEATURE_FRED
> > +
> >   	/*
> > -	 * Objtool doesn't understand what ERETS does, this hint tells it that
> > -	 * yes, we'll reach here and with what stack state. A save/restore pair
> > -	 * isn't strictly needed, but it's the simplest form.
> > +	 * Objtool doesn't understand ERETS, and the cfi register state is
> > +	 * different from initial_func_cfi due to PUSH_REGS. Tell it the state
> > +	 * is similar to where UNWIND_HINT_SAVE is.
> >   	 */
> >   	UNWIND_HINT_RESTORE
> > +
> >   	pop %rbp
> >   	RET
>