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

[Kim Phillips <kim.phillips@amd.com>]

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@amd.com>
>> Cc: Borislav Petkov (AMD) <bp@alien8.de>
>> Cc: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
>> Cc: Dave Hansen <dave.hansen@linux.intel.com>
>> Cc: Sean Christopherson <seanjc@google.com>
>> Cc: stable@kernel.org
> Definitely not stable material. If at all.
>> Reported-by: kernel test robot <lkp@intel.com>
>> Closes: https://lore.kernel.org/oe-kbuild-all/202603121136.bc8zNsHS-lkp@intel.com/
> 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@amd.com/

Thanks,

Kim