Re: [PATCH v4 02/10] cpu/bugs: Allow forcing Automatic IBRS with SNP active using spectre_v2=eibrs

[Kim Phillips]

On 8/18/26 6:22 PM, Borislav Petkov wrote:
> On Tue, Aug 04, 2026 at 06:56:03PM -0500, Kim Phillips wrote:
>
> Please fix all your subject prefixes: it should be "x86/bugs:"
>
> The tip tree preferred format for patch subject prefixes is
> 'subsys/component:', e.g. 'x86/apic:', 'x86/mm/fault:', 'sched/fair:',
> 'genirq/core:'. Please do not use file names or complete file paths as
> prefix. 'git log path/to/file' should give you a reasonable hint in most
> cases.
>
> > spectre_v2=eibrs currently enables retpolines when SNP is enabled,
> > instead of AutoIBRS (EIBRS) because the commit that disabled
> > AutoIBRS if SNP is enabled stopped short of enabling
> > X86_FEATURE_IBRS_ENHANCED.
> >
> > Change the logic to enable X86_FEATURE_IBRS_ENHANCED, and move the
> > decision to switch to retpolines in the default/"auto" case in
> > spectre_v2_select_mitigation().  This allows the existing
> > spectre_v2=eibrs logic to work as intended.
> So this whole hoopla is just to be able to select =eibrs in SNP guests, *and*,
> in doing so, cause a performance loss. I.e., shoot oneself in the foot.
>
> Or is there another, better reason which wants this?
It's not in guests, it's in the hypervisor, and in addition to making 
spectre_v2=eibrs work as advertised, it also fixes emitting the 
misleading "EIBRS selected but CPU doesn't have Enhanced or Automatic 
IBRS." on AutoIBRS-capable CPUs.

Shooting oneself in the foot is subjective depending on what performance 
users want and whether in userspace or not, esp. considering this series 
also enables spectre_v2=ibrs on SNP hosts.

> > Fixes: acaa4b5c4c85 ("x86/speculation: Do not enable Automatic IBRS if SEV-SNP is enabled")
> > Reported-by: Tom Lendacky <thomas.lendacky@xxxxxxx>
> > Cc: Borislav Petkov (AMD) <bp@xxxxxxxxx>
> > Cc: Pawan Gupta <pawan.kumar.gupta@xxxxxxxxxxxxxxx>
> > Cc: Dave Hansen <dave.hansen@xxxxxxxxxxxxxxx>
> > Cc: Sean Christopherson <seanjc@xxxxxxxxxx>
> > Cc: stable@xxxxxxxxxx
> Definitely not stable material. If at all.
> > Reported-by: kernel test robot <lkp@xxxxxxxxx>
> > Closes: https://lore.kernel.org/oe-kbuild-all/202603121136.bc8zNsHS-lkp@xxxxxxxxx/
> It doesn't close that - that link points to something which is not upstream.
These get dropped in v5 - please switch to reviewing v5 now:

https://lore.kernel.org/lkml/20260826223510.3669875-1-kim.phillips@xxxxxxx/

Thanks,

Kim