Re: [PATCH v12 09/12] x86/vmscape: Use static_call() for predictor flush

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [Medium] The patch introduces unconditional memory reads on the highly sensitive kernel-to-user exit and KVM VM-enter fast paths, penalizing all systems where the VMSCAPE mitigation is disabled.
- [Low] The removal of `X86_FEATURE_IBPB_EXIT_TO_USER` from the kernel CPU features header was not mirrored to the corresponding tools header, causing code drift.
- [Low] Usage of `static_call_cond()` without including `<linux/static_call.h>` makes the header non-self-contained.
--

commit 6813e9ba3f5da52dd0859a742860cd03837d50a7
Author: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>

x86/vmscape: Use static_call() for predictor flush

This patch replaces the flag-based mitigation selector for VMSCAPE with a
static_call() to the mitigating function. This avoids adding more feature
flags and multiple checks, freeing the X86_FEATURE_IBPB_EXIT_TO_USER flag.

> diff --git a/arch/x86/include/asm/cpufeatures.h b/arch/x86/include/asm/cpufeatures.h
> index 1d506e5d6f46a..09f956b72637c 100644
> --- a/arch/x86/include/asm/cpufeatures.h
> +++ b/arch/x86/include/asm/cpufeatures.h
> @@ -504,7 +504,7 @@
>  #define X86_FEATURE_TSA_SQ_NO		(21*32+11) /* AMD CPU not vulnerable to TSA-SQ */
>  #define X86_FEATURE_TSA_L1_NO		(21*32+12) /* AMD CPU not vulnerable to TSA-L1 */
>  #define X86_FEATURE_CLEAR_CPU_BUF_VM	(21*32+13) /* Clear CPU buffers using VERW before VMRUN */
> -#define X86_FEATURE_IBPB_EXIT_TO_USER	(21*32+14) /* Use IBPB on exit-to-userspace, see VMSCAPE bug */
> +/* Free */

[Severity: Low]
Does this removal also need to be synced to the tools copy in
tools/arch/x86/include/asm/cpufeatures.h? Leaving them out of sync typically
triggers a 'Kernel ABI header differs' build warning when compiling tools
like perf.

[ ... ]

> diff --git a/arch/x86/include/asm/entry-common.h b/arch/x86/include/asm/entry-common.h
> index 3be6d4c356ed2..d5b390c76f000 100644
> --- a/arch/x86/include/asm/entry-common.h
> +++ b/arch/x86/include/asm/entry-common.h
> @@ -4,6 +4,7 @@
>  
>  #include <linux/randomize_kstack.h>
>  #include <linux/user-return-notifier.h>
> +#include <linux/static_call_types.h>

[Severity: Low]
Should this include <linux/static_call.h> instead? The static_call_cond()
macro is used below but isn't defined in static_call_types.h, which could
cause build failures if relying on implicit dependencies from downstream C
files.

>  
>  #include <asm/nospec-branch.h>
>  #include <asm/io_bitmap.h>
> @@ -82,10 +83,8 @@ static inline void arch_exit_to_user_mode_prepare(struct pt_regs *regs,
>  	current_thread_info()->status &= ~(TS_COMPAT | TS_I386_REGS_POKED);
>  #endif
>  
> -	/* Avoid unnecessary reads of 'x86_predictor_flush_exit_to_user' */
> -	if (cpu_feature_enabled(X86_FEATURE_IBPB_EXIT_TO_USER) &&
> -	    this_cpu_read(x86_predictor_flush_exit_to_user)) {
> -		write_ibpb();
> +	if (unlikely(this_cpu_read(x86_predictor_flush_exit_to_user))) {

[Severity: Medium]
Will this unconditional per-CPU memory read add overhead on the kernel to
user exit fast path for unaffected CPUs? The previous cpu_feature_enabled()
check used alternative patching to compile out to zero instructions when the
mitigation was disabled.

> +		static_call_cond(vmscape_predictor_flush)();
>  		this_cpu_write(x86_predictor_flush_exit_to_user, false);
>  	}
>  }

[ ... ]

> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 721ff7667dc0b..fcd61c47653fa 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -11556,7 +11556,7 @@ static int vcpu_enter_guest(struct kvm_vcpu *vcpu)
>  	 * set for the CPU that actually ran the guest, and not the CPU that it
>  	 * may migrate to.
>  	 */
> -	if (cpu_feature_enabled(X86_FEATURE_IBPB_EXIT_TO_USER))
> +	if (static_call_query(vmscape_predictor_flush))

[Severity: Medium]
Does replacing cpu_feature_enabled() with static_call_query() penalize the
KVM VM-enter fast path for unaffected hosts by introducing an unconditional
global memory read?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260622-vmscape-bhb-v12-0-76cbda0ae3e5@linux.intel.com?part=9