Re: [PATCH v10 05/28] x86/cea: Use array indexing to simplify exception stack access

[Sohil Mehta <sohil.mehta@intel.com>]

On 9/11/2026 2:57 PM, sashiko-bot@kernel.org wrote:

>> +/*
>> + * Typically invoked by entry code, so must be noinstr.
>> + */
>> +noinstr unsigned long __this_cpu_ist_bottom_va(enum exception_stack_ordering stack)
>> +{
>> +	struct cea_exception_stacks *s;
>> +
>> +	BUILD_BUG_ON(ESTACK_DF != 0);
>> +	BUG_ON(stack >= N_EXCEPTION_STACKS);
> 
> [Severity: Medium]
> Does moving these helpers from macros in the header to out-of-line functions
> introduce an unintended performance regression?
> 
> Because the functions are defined out-of-line in a different translation unit,
> the compiler cannot statically evaluate the BUG_ON(stack >= N_EXCEPTION_STACKS)
> bounds checks nor inline the pointer math.
> 
> This incurs a penalty of multiple function calls and dynamic checks in
> performance-sensitive #VC exception entry paths. For example, hot paths like
> is_vc2_stack() in arch/x86/coco/sev/vc-handle.c repeatedly call these functions,
> which are evaluated on every #VC exception:
> 
> arch/x86/coco/sev/vc-handle.c:is_vc2_stack() {
>     ...
>     return (sp >= __this_cpu_ist_bottom_va(ESTACK_VC2) &&
>             sp < __this_cpu_ist_top_va(ESTACK_VC2));
> }
> 
> Could this regression in a noinstr entry path be avoided by defining these
> helpers as static __always_inline in the header instead?
> 

The performance regression concern seems overblown to me. The #VC
handling has other heavy-handed things such as GHCB and VMGEXIT. The
extra cycles for __this_cpu_ist_bottom_va() and __this_cpu_ist_top_va()
shouldn't have any meaningful impact.

I am thinking of avoiding the __always_inline directive unless someone
has a strong reason/preference.

>> +
>> +	s = __this_cpu_read(cea_exception_stacks);
>> +
>> +	return (unsigned long)&s->event_stacks[stack].stack;
>> +}
>