[PATCH v4 00/10] KVM: SEV: Add support for IBPB-on-Entry and BTB Isolation

[PATCH v4 00/10] KVM: SEV: Add support for IBPB-on-Entry and BTB Isolation

[Kim Phillips]

IBPB-on-Entry and BTB Isolation are supplemental Spectre V2 mitigations
available to SNP guests.

Patch 1 fixes a misleading no-spectre-v2-mitigation error when the kernel isn't
compiled with retpolines, but a user can still select AutoIBRS, for example.

Patch 2 fixes a longstanding bug where users weren't able
to force Automatic IBRS on SNP enabled machines using spectre_v2=eibrs.

Patch 3 allows AutoIBRS to be used on a kernel compiled without retpolines.

Patch 4 fixes another longstanding bug where users couldn't
select legacy / toggling SPEC_CTRL[IBRS] on AMD systems.  Users of
the BTB Isolation feature may use IBRS to mitigate possible
performance degradation caused by BTB Isolation.

Patches 5, 6, 7 and 8 deal with code refactoring as a result of
Sean's review of the v2 IBPB-on-Entry series: an SNP-only feature
mask.

Patch 9 adds support for IBPB-on-Entry.

Patch 10 adds support for BTB Isolation.

Based on tip/master (currently fd0ece3c0826):
https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

This v4 series now also available here:

https://github.com/AMDESE/linux/tree/btb-isol-latest

Advance qemu bits (to add feature on/off switches) available here:

https://github.com/AMDESE/qemu/tree/btb-isol-latest

Qemu bits will be posted upstream once kernel bits are merged.
They depend on Naveen Rao's "target/i386: SEV: Add support for
enabling VMSA SEV features":

https://lore.kernel.org/qemu-devel/cover.1761648149.git.naveen@kernel.org/

v4:
   - Ran Sashiko in a loop until all(?) its comments were addressed (Boris)

v3:
   - https://lore.kernel.org/kvm/20260402202558.195005-1-kim.phillips@amd.com/
   - Merged IBPB-on-Entry and BTB Isolation into single patchseries
   - Addressed comments from Sean Christopherson, Pawan Gupta, kernel test robot
   - Simplified unnecessarily complicated logic in spectre_v2=eibrs-with-SNP fix
   - Reworded, rebased features on top of new SNP_ONLY_MASK etc. changes

v2:
[IBPB-on-Entry]
     - https://lore.kernel.org/kvm/20260203222405.4065706-1-kim.phillips@amd.com/
     - Change first patch's title (Nikunj)
     - Add reviews-by (Nikunj, Tom)
     - Change second patch's description to more generally explain what the patch does (Boris)
     - Add new, third patch renaming SNP_FEATURES_PRESENT->SNP_FEATURES_IMPL
[BTB Isolation]
     - https://lore.kernel.org/kvm/20260311130611.2201214-1-kim.phillips@amd.com/
     - Patch 1/3:
       - Address Dave Hansen's comment to adhere to using the IBRS_ENHANCED
         Intel feature flag also for AutoIBRS.

v1:
[IBPB-on-Entry] https://lore.kernel.org/kvm/20260126224205.1442196-1-kim.phillips@amd.com/
[BTB Isolation] https://lore.kernel.org/kvm/20260224180157.725159-1-kim.phillips@amd.com/

Kim Phillips (10):
  x86/bugs: Only log missing retpoline when it's actually the missing
    mitigation
  cpu/bugs: Allow forcing Automatic IBRS with SNP active using
    spectre_v2=eibrs
  cpu/bugs: Fall back to AutoIBRS when retpoline unavailable on SNP CPUs
  cpu/bugs: Allow spectre_v2=ibrs on x86 vendors other than Intel
  KVM: SEV: Define SVM_SEV_FEAT_* flags using BIT_ULL()
  KVM: selftests: sev_init2: Use BIT_ULL for VMSA feature bit definition
  KVM: SEV: Disallow setting SNP-only features for non-SNP guests via a
    single mask
  KVM: SEV: Advertise SVM_SEV_FEAT_SNP_ACTIVE
  KVM: SEV: Add support for IBPB-on-Entry
  KVM: SEV: Add support for SNP BTB Isolation

 arch/x86/Kconfig                              |  7 +-
 arch/x86/include/asm/cpufeatures.h            |  1 +
 arch/x86/include/asm/svm.h                    | 17 +++--
 arch/x86/kernel/cpu/bugs.c                    | 71 ++++++++++++++-----
 arch/x86/kernel/cpu/common.c                  |  6 +-
 arch/x86/kvm/svm/sev.c                        | 18 ++++-
 tools/arch/x86/include/asm/cpufeatures.h      |  1 +
 .../selftests/kvm/x86/sev_init2_tests.c       | 20 ++++--
 8 files changed, 103 insertions(+), 38 deletions(-)


base-commit: fd0ece3c082632334ded22076932b302a048c7de
-- 
2.43.0

[PATCH v4 01/10] x86/bugs: Only log missing retpoline when it's actually the missing mitigation

[Kim Phillips]

spectre_v2_select_retpoline() unconditionally emits a pr_err when the
kernel lacks retpoline support before returning SPECTRE_V2_NONE to its
callers.  A caller may then select an alternative mitigation, making the
"no mitigation available!" message alarming and misleading to
administrators on a system that is actually mitigated.

Drop the pr_err from the helper and emit it once from
spectre_v2_update_mitigation().  Guard it on
!IS_ENABLED(CONFIG_MITIGATION_RETPOLINE) so it only fires when retpoline
truly cannot be built in, and restrict it to the cases where retpoline
was the implied choice: SPECTRE_V2_CMD_FORCE, or SPECTRE_V2_CMD_AUTO
when should_mitigate_vuln(X86_BUG_SPECTRE_V2) indicates we actually
intended to mitigate.  This avoids the spurious error on a
CONFIG_MITIGATION_RETPOLINE=n kernel where a caller of
spectre_v2_select_retpoline() selects an alternative mitigation, leaving
the system protected while the old message claimed otherwise.

Cc: stable@kernel.org
Signed-off-by: Kim Phillips <kim.phillips@amd.com>
Assisted-by: ClaudeCode:claude-opus-4-7
---
 arch/x86/kernel/cpu/bugs.c | 11 ++++++++---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
index ddf0db5326fa..b345f64f4258 100644
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -1956,10 +1956,8 @@ early_param("spectre_v2", spectre_v2_parse_cmdline);
 
 static enum spectre_v2_mitigation __init spectre_v2_select_retpoline(void)
 {
-	if (!IS_ENABLED(CONFIG_MITIGATION_RETPOLINE)) {
-		pr_err("Kernel not compiled with retpoline; no mitigation available!");
+	if (!IS_ENABLED(CONFIG_MITIGATION_RETPOLINE))
 		return SPECTRE_V2_NONE;
-	}
 
 	return SPECTRE_V2_RETPOLINE;
 }
@@ -2247,6 +2245,13 @@ static void __init spectre_v2_update_mitigation(void)
 		}
 	}
 
+	if (!IS_ENABLED(CONFIG_MITIGATION_RETPOLINE) &&
+	    spectre_v2_enabled == SPECTRE_V2_NONE &&
+	    (spectre_v2_cmd == SPECTRE_V2_CMD_FORCE ||
+	     (spectre_v2_cmd == SPECTRE_V2_CMD_AUTO &&
+	      should_mitigate_vuln(X86_BUG_SPECTRE_V2))))
+		pr_err("Kernel not compiled with retpoline; no mitigation available!");
+
 	if (boot_cpu_has_bug(X86_BUG_SPECTRE_V2))
 		pr_info("%s\n", spectre_v2_strings[spectre_v2_enabled]);
 }
-- 
2.43.0

Re: [PATCH v4 01/10] x86/bugs: Only log missing retpoline when it's actually the missing mitigation

[Borislav Petkov]

On Tue, Aug 04, 2026 at 06:56:02PM -0500, Kim Phillips wrote:
> spectre_v2_select_retpoline() unconditionally emits a pr_err when the
> kernel lacks retpoline support before returning SPECTRE_V2_NONE to its
> callers.

Unconditionally? There's an "if" there. :)

> A caller may then select an alternative mitigation, making the "no
> mitigation available!" message alarming and misleading to administrators on
> a system that is actually mitigated.
> 
> Drop the pr_err from the helper and emit it once from
> spectre_v2_update_mitigation().  Guard it on
> !IS_ENABLED(CONFIG_MITIGATION_RETPOLINE) so it only fires when retpoline
> truly cannot be built in,

This is explaining the diff. Doesn't belong in the commit message.

> and restrict it to the cases where retpoline
> was the implied choice: SPECTRE_V2_CMD_FORCE, or SPECTRE_V2_CMD_AUTO
> when should_mitigate_vuln(X86_BUG_SPECTRE_V2) indicates we actually
> intended to mitigate. 

> This avoids the spurious error on a
> CONFIG_MITIGATION_RETPOLINE=n kernel where a caller of
> spectre_v2_select_retpoline() selects an alternative mitigation, leaving
> the system protected while the old message claimed otherwise.

This should be your first sentence. What the issue is.

Which begs the question: why?

Why do we care about a CONFIG_MITIGATION_RETPOLINE=n kernel?

You either disable all mitigations or enable them all (distro kernel) and they
get then configured at boot time. Why would I want to disable RETPOLINE only
but leave spectre v2?

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Re: [PATCH v4 01/10] x86/bugs: Only log missing retpoline when it's actually the missing mitigation

[Kim Phillips]

On 8/4/26 7:44 PM, Borislav Petkov wrote:
> On Tue, Aug 04, 2026 at 06:56:02PM -0500, Kim Phillips wrote:
>> spectre_v2_select_retpoline() unconditionally emits a pr_err when the
>> kernel lacks retpoline support before returning SPECTRE_V2_NONE to its
>> callers.
> 
> Unconditionally? There's an "if" there. :)

There's a "when" in there, too:

...unconditionally (emits a pr_err when the kernel lacks retpoline support) before...

So it's saying there are no additional conditions than
!IS_ENABLED(CONFIG_MITIGATION_RETPOLINE), when there should be
(which this patch adds).

>> A caller may then select an alternative mitigation, making the "no
>> mitigation available!" message alarming and misleading to administrators on
>> a system that is actually mitigated.
>>
>> Drop the pr_err from the helper and emit it once from
>> spectre_v2_update_mitigation().  Guard it on
>> !IS_ENABLED(CONFIG_MITIGATION_RETPOLINE) so it only fires when retpoline
>> truly cannot be built in,
> 
> This is explaining the diff. Doesn't belong in the commit message.

Ok

>> and restrict it to the cases where retpoline
>> was the implied choice: SPECTRE_V2_CMD_FORCE, or SPECTRE_V2_CMD_AUTO
>> when should_mitigate_vuln(X86_BUG_SPECTRE_V2) indicates we actually
>> intended to mitigate.
> 
>> This avoids the spurious error on a
>> CONFIG_MITIGATION_RETPOLINE=n kernel where a caller of
>> spectre_v2_select_retpoline() selects an alternative mitigation, leaving
>> the system protected while the old message claimed otherwise.
> 
> This should be your first sentence. What the issue is.

I'll see about rewording the commit text according to this and all your
above comments in the next version.

> Which begs the question: why?
> 
> Why do we care about a CONFIG_MITIGATION_RETPOLINE=n kernel?
> 
> You either disable all mitigations or enable them all (distro kernel) and they
> get then configured at boot time. Why would I want to disable RETPOLINE only
> but leave spectre v2?
This patch corrects code that already cares about RETPOLINE=n kernels, but
it's also useful if you know all the target systems for a RETPOLINE=n config have
alternatives to RETPOLINE, such as {,e,Auto}IBRS.  This will become more and more
true as time goes by.

Thanks,

Kim

Re: [PATCH v4 01/10] x86/bugs: Only log missing retpoline when it's actually the missing mitigation

[Borislav Petkov]

On Wed, Aug 05, 2026 at 09:51:11AM -0500, Kim Phillips wrote:
> So it's saying there are no additional conditions than
> !IS_ENABLED(CONFIG_MITIGATION_RETPOLINE), when there should be
> (which this patch adds).

Then say that pls.

> This patch corrects code that already cares about RETPOLINE=n kernels, but
> it's also useful if you know all the target systems for a RETPOLINE=n config have
> alternatives to RETPOLINE, such as {,e,Auto}IBRS.  This will become more and more
> true as time goes by.

Why would more and more configs become relevant which disable
CONFIG_MITIGATION_RETPOLINE?

What is the compelling use case which warrants to have this in the upstream
kernel?

Give me a concrete example pls.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Re: [PATCH v4 01/10] x86/bugs: Only log missing retpoline when it's actually the missing mitigation

[Kim Phillips]

On 8/5/26 5:49 PM, Borislav Petkov wrote:
> On Wed, Aug 05, 2026 at 09:51:11AM -0500, Kim Phillips wrote:
>> This patch corrects code that already cares about RETPOLINE=n kernels, but
>> it's also useful if you know all the target systems for a RETPOLINE=n config have
>> alternatives to RETPOLINE, such as {,e,Auto}IBRS.  This will become more and more
>> true as time goes by.
> Why would more and more configs become relevant which disable
> CONFIG_MITIGATION_RETPOLINE?
>
> What is the compelling use case which warrants to have this in the upstream
> kernel?
If by 'this' you mean this patch, it's because it fixes a bug with 
RETPOLINE=n kernels that sashiko found when reviewing the rest of the 
patches in the series.

If by 'this' you mean RETPOLINE=n configurability in general, this patch 
isn't adding or removing that.

Thanks,

Kim

Re: [PATCH v4 01/10] x86/bugs: Only log missing retpoline when it's actually the missing mitigation

[Borislav Petkov]

On Thu, Aug 06, 2026 at 03:12:12PM -0500, Kim Phillips wrote:
> If by 'this' you mean this patch, it's because it fixes a bug with
> RETPOLINE=n kernels that sashiko found when reviewing the rest of the
> patches in the series.
> 
> If by 'this' you mean RETPOLINE=n configurability in general, this patch
> isn't adding or removing that.

Neither of those things warrant to have this patch, *especially* in bugs.c
which is a nightmare as it is already.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Re: [PATCH v4 01/10] x86/bugs: Only log missing retpoline when it's actually the missing mitigation

[Kim Phillips]

On 8/7/26 12:44 AM, Borislav Petkov wrote:
> On Thu, Aug 06, 2026 at 03:12:12PM -0500, Kim Phillips wrote:
>> If by 'this' you mean this patch, it's because it fixes a bug with
>> RETPOLINE=n kernels that sashiko found when reviewing the rest of the
>> patches in the series.
>>
>> If by 'this' you mean RETPOLINE=n configurability in general, this patch
>> isn't adding or removing that.
> 
> Neither of those things warrant to have this patch, *especially* in bugs.c
> which is a nightmare as it is already.
It fixes a bug.  If you don't want it, drop it, but know that sashiko
will continue to complain, and previously you said you had wanted
sashiko comments addressed.

Meanwhile, please review of the rest of the series.

Thanks,

Kim

Re: [PATCH v4 01/10] x86/bugs: Only log missing retpoline when it's actually the missing mitigation

[Borislav Petkov]

On Mon, Aug 10, 2026 at 06:21:01PM -0500, Kim Phillips wrote:
> It fixes a bug.  If you don't want it, drop it, but know that sashiko
> will continue to complain, and previously you said you had wanted
> sashiko comments addressed.

"Addressed" doesn't mean "patch applied so that some random tool doesn't
complain anymore." It could also mean: "noted, but the issue is not relevant
enough to do a fix, all things considered."

> Meanwhile, please review of the rest of the series.

I told you last week on internal chat: "You don't have to hurry anyway,
though, as it is too late already for this cycle" after saying that I will go
through them.

Did anything change since then?

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

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

[Kim Phillips]

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.

Also emit a performance loss warning for using AutoIBRS with SNP
enabled.  AutoIBRS is activated for all three eIBRS modes via
spectre_v2_in_eibrs_mode(), so use that helper to cover
spectre_v2=eibrs, spectre_v2=eibrs,lfence, and
spectre_v2=eibrs,retpoline uniformly.  Word the warning in terms of the
eIBRS mitigation enabling AutoIBRS, rather than naming AutoIBRS as the
selected mitigation, so it reads correctly for the ,lfence and
,retpoline variants where another component is also active.

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
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202603121136.bc8zNsHS-lkp@intel.com/
Signed-off-by: Kim Phillips <kim.phillips@amd.com>
Assisted-by: ClaudeCode:claude-opus-4-7
---
 arch/x86/kernel/cpu/bugs.c   | 12 +++++++++++-
 arch/x86/kernel/cpu/common.c |  6 +-----
 2 files changed, 12 insertions(+), 6 deletions(-)

diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
index b345f64f4258..a813a98ac5bd 100644
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -1672,6 +1672,7 @@ static inline bool retpoline_seq_enabled(void) { return false; }
 #define SPECTRE_V2_LFENCE_MSG "WARNING: LFENCE mitigation is not recommended for this CPU, data leaks possible!\n"
 #define SPECTRE_V2_EIBRS_EBPF_MSG "WARNING: Unprivileged eBPF is enabled with eIBRS on, data leaks possible via Spectre v2 BHB attacks!\n"
 #define SPECTRE_V2_EIBRS_LFENCE_EBPF_SMT_MSG "WARNING: Unprivileged eBPF is enabled with eIBRS+LFENCE mitigation and SMT, data leaks possible via Spectre v2 BHB attacks!\n"
+#define SPECTRE_V2_EIBRS_SNP_PERF_MSG "WARNING: eIBRS mitigation enables AutoIBRS on SEV-SNP enabled CPU, this may cause performance loss\n"
 #define SPECTRE_V2_IBRS_PERF_MSG "WARNING: IBRS mitigation selected on Enhanced IBRS CPU, this may cause unnecessary performance loss\n"
 
 #ifdef CONFIG_BPF_SYSCALL
@@ -2192,7 +2193,12 @@ static void __init spectre_v2_select_mitigation(void)
 			break;
 		fallthrough;
 	case SPECTRE_V2_CMD_FORCE:
-		if (boot_cpu_has(X86_FEATURE_IBRS_ENHANCED)) {
+		/*
+		 * Don't use AutoIBRS when SNP is enabled because it degrades
+		 * host userspace indirect branch performance.
+		 */
+		if (boot_cpu_has(X86_FEATURE_IBRS_ENHANCED) &&
+		    !boot_cpu_has(X86_FEATURE_SEV_SNP)) {
 			spectre_v2_enabled = SPECTRE_V2_EIBRS;
 			break;
 		}
@@ -2291,6 +2297,10 @@ static void __init spectre_v2_apply_mitigation(void)
 		}
 	}
 
+	if (spectre_v2_in_eibrs_mode(spectre_v2_enabled) &&
+	    boot_cpu_has(X86_FEATURE_SEV_SNP))
+		pr_warn(SPECTRE_V2_EIBRS_SNP_PERF_MSG);
+
 	switch (spectre_v2_enabled) {
 	case SPECTRE_V2_NONE:
 		return;
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index fa429f04f003..8387d3a49c43 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -1496,13 +1496,9 @@ static void __init cpu_set_bug_bits(struct cpuinfo_x86 *c)
 	/*
 	 * AMD's AutoIBRS is equivalent to Intel's eIBRS - use the Intel feature
 	 * flag and protect from vendor-specific bugs via the whitelist.
-	 *
-	 * Don't use AutoIBRS when SNP is enabled because it degrades host
-	 * userspace indirect branch performance.
 	 */
 	if ((x86_arch_cap_msr & ARCH_CAP_IBRS_ALL) ||
-	    (cpu_has(c, X86_FEATURE_AUTOIBRS) &&
-	     !cpu_feature_enabled(X86_FEATURE_SEV_SNP))) {
+	    cpu_has(c, X86_FEATURE_AUTOIBRS)) {
 		setup_force_cpu_cap(X86_FEATURE_IBRS_ENHANCED);
 		if (!cpu_matches(cpu_vuln_whitelist, NO_EIBRS_PBRSB) &&
 		    !(x86_arch_cap_msr & ARCH_CAP_PBRSB_NO))
-- 
2.43.0

[PATCH v4 03/10] cpu/bugs: Fall back to AutoIBRS when retpoline unavailable on SNP CPUs

[Kim Phillips]

When the kernel is compiled without CONFIG_MITIGATION_RETPOLINE,
spectre_v2_select_retpoline() returns SPECTRE_V2_NONE, leaving SNP
hosts with AutoIBRS completely unmitigated against Spectre v2 in the
default/auto case.

Since SNP CPUs have AutoIBRS available, fall back to SPECTRE_V2_EIBRS
rather than leaving the system unmitigated.  The preceding commit already
enables AutoIBRS (and sets X86_FEATURE_IBRS_ENHANCED) on SNP parts, so no
additional feature-bit fixup is needed here; only the mitigation
selection changes when retpoline is unavailable.

Fixes: acaa4b5c4c85 ("x86/speculation: Do not enable Automatic IBRS if SEV-SNP is enabled")
Cc: stable@kernel.org
Signed-off-by: Kim Phillips <kim.phillips@amd.com>
Assisted-by: ClaudeCode:claude-opus-4-7
---
 arch/x86/kernel/cpu/bugs.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
index a813a98ac5bd..6a036b509f0b 100644
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -2204,6 +2204,15 @@ static void __init spectre_v2_select_mitigation(void)
 		}
 
 		spectre_v2_enabled = spectre_v2_select_retpoline();
+		/*
+		 * If retpoline is unavailable (e.g. built without
+		 * CONFIG_MITIGATION_RETPOLINE), fall back to eIBRS on
+		 * AutoIBRS-capable parts rather than leaving SNP hosts
+		 * unmitigated.
+		 */
+		if (spectre_v2_enabled == SPECTRE_V2_NONE &&
+		    boot_cpu_has(X86_FEATURE_AUTOIBRS))
+			spectre_v2_enabled = SPECTRE_V2_EIBRS;
 		break;
 
 	case SPECTRE_V2_CMD_RETPOLINE_LFENCE:
-- 
2.43.0

[PATCH v4 04/10] cpu/bugs: Allow spectre_v2=ibrs on x86 vendors other than Intel

[Kim Phillips]

Prepare for legacy IBRS toggling on AMD, where the BTB Isolation
SEV-SNP feature uses it to optimize the VM exit-to-re-entry path.
There is no reason this wasn't allowed in the first place, hence
the Fixes: and stable tags.

Keep the IBRS-trumps-retbleed logic in retbleed_update_mitigation()
Intel-only.  Legacy SPEC_CTRL.IBRS does not mitigate AMD's Branch
Type Confusion RETBleed variant (RET prediction uses the Return
Address Predictor, not the indirect branch predictors IBRS
restricts), so letting SPECTRE_V2_IBRS trump retbleed on AMD would
silently drop the UNRET/IBPB mitigation that does cover it.

On AMD the decoupling is total: retbleed mitigation selection never
consults spectre_v2=, so spectre_v2=ibrs neither adds nor removes
RETBleed coverage.  A kernel built without MITIGATION_UNRET_ENTRY and
MITIGATION_IBPB_ENTRY already reports RETBleed as "Vulnerable" via the
retbleed sysfs node and boot log regardless of the spectre_v2= value,
so there is no silent gap in the spectre_v2=ibrs path to warn about --
and a warning there would wrongly imply the Intel-style IBRS/RETBleed
coupling exists on AMD.

Also drop CPU_SUP_INTEL from CONFIG_MITIGATION_IBRS_ENTRY's depends
line: the IBRS_ENTER/IBRS_EXIT macros are vendor-neutral, and the
Intel-only restriction would silently redirect spectre_v2=ibrs to
AUTO on AMD-only kernels.

Explicitly set or clear EFER.AUTOIBRS to match the selected mitigation
on AutoIBRS-capable CPUs: set it in eIBRS mode, and clear it in every
other mode -- NONE, retpoline, LFENCE and the legacy IBRS path alike.
head_64.S preserves incoming EFER bits, so a kexec from an
eIBRS/AutoIBRS kernel carries EFER.AUTOIBRS into the new kernel; without
an explicit clear the CPU stays in AutoIBRS mode while sysfs reports
e.g. "Mitigation: IBRS" or a retpoline mode, diverging from the actual
hardware state.  On a normal cold boot the bit is already clear, so the
msr_clear_bit() is a no-op there.  Clearing on the boot CPU suffices for
APs, since it precedes the init_real_mode() EFER snapshot used by the AP
trampoline.

Fixes: 7c693f54c873 ("x86/speculation: Add spectre_v2=ibrs option to support Kernel IBRS")
Reported-by: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
Cc: Borislav Petkov (AMD) <bp@alien8.de>
Cc: stable@kernel.org
Signed-off-by: Kim Phillips <kim.phillips@amd.com>
Assisted-by: ClaudeCode:claude-opus-4-7
---
 arch/x86/Kconfig           |  7 ++++---
 arch/x86/kernel/cpu/bugs.c | 39 ++++++++++++++++++++++++++------------
 2 files changed, 31 insertions(+), 15 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index e725b439d0a2..4bd91d41dbba 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2492,12 +2492,13 @@ config MITIGATION_IBPB_ENTRY
 
 config MITIGATION_IBRS_ENTRY
 	bool "Enable IBRS on kernel entry"
-	depends on CPU_SUP_INTEL && X86_64
+	depends on X86_64
 	default y
 	help
 	  Compile the kernel with support for the spectre_v2=ibrs mitigation.
-	  This mitigates both spectre_v2 and retbleed at great cost to
-	  performance.
+	  This mitigates spectre_v2 at great cost to performance.  On Intel,
+	  it also mitigates retbleed.  On AMD/Hygon, retbleed mitigation
+	  requires MITIGATION_UNRET_ENTRY or MITIGATION_IBPB_ENTRY.
 
 config MITIGATION_SRSO
 	bool "Mitigate speculative RAS overflow on AMD"
diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
index 6a036b509f0b..245de4ea8d60 100644
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -1305,7 +1305,14 @@ static void __init retbleed_update_mitigation(void)
 
 	/*
 	 * Let IBRS trump all on Intel without affecting the effects of the
-	 * retbleed= cmdline option except for call depth based stuffing
+	 * retbleed= cmdline option except for call depth based stuffing.
+	 *
+	 * On AMD/Hygon, legacy SPEC_CTRL.IBRS toggling does not mitigate the
+	 * Branch Type Confusion RETBleed variant: RET prediction comes from
+	 * the Return Address Predictor, not the restricted indirect branch
+	 * predictors that IBRS controls.  So keep this Intel-only and leave
+	 * AMD's software return-thunk mitigation (UNRET/IBPB) in place even
+	 * when spectre_v2=ibrs is selected.
 	 */
 	if (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL) {
 		switch (spectre_v2_enabled) {
@@ -2164,11 +2171,6 @@ static void __init spectre_v2_select_mitigation(void)
 		spectre_v2_cmd = SPECTRE_V2_CMD_AUTO;
 	}
 
-	if (spectre_v2_cmd == SPECTRE_V2_CMD_IBRS && boot_cpu_data.x86_vendor != X86_VENDOR_INTEL) {
-		pr_err("IBRS selected but not Intel CPU. Switching to AUTO select\n");
-		spectre_v2_cmd = SPECTRE_V2_CMD_AUTO;
-	}
-
 	if (spectre_v2_cmd == SPECTRE_V2_CMD_IBRS && !boot_cpu_has(X86_FEATURE_IBRS)) {
 		pr_err("IBRS selected but CPU doesn't have IBRS. Switching to AUTO select\n");
 		spectre_v2_cmd = SPECTRE_V2_CMD_AUTO;
@@ -2297,13 +2299,26 @@ static void __init spectre_v2_apply_mitigation(void)
 	if (spectre_v2_enabled == SPECTRE_V2_EIBRS && unprivileged_ebpf_enabled())
 		pr_err(SPECTRE_V2_EIBRS_EBPF_MSG);
 
-	if (spectre_v2_in_ibrs_mode(spectre_v2_enabled)) {
-		if (boot_cpu_has(X86_FEATURE_AUTOIBRS)) {
+	/*
+	 * head_64.S preserves EFER.AUTOIBRS across boot, so a kexec from a
+	 * kernel that ran in AutoIBRS mode carries the bit into the new kernel.
+	 * Explicitly set or clear it to match the selected mitigation, regardless
+	 * of which mode is in effect.  The boot CPU does this before
+	 * init_real_mode() snapshots EFER for the AP trampoline, so APs inherit
+	 * the correct value too.
+	 */
+	if (boot_cpu_has(X86_FEATURE_AUTOIBRS)) {
+		if (spectre_v2_in_eibrs_mode(spectre_v2_enabled))
 			msr_set_bit(MSR_EFER, _EFER_AUTOIBRS);
-		} else {
-			x86_spec_ctrl_base |= SPEC_CTRL_IBRS;
-			update_spec_ctrl(x86_spec_ctrl_base);
-		}
+		else
+			msr_clear_bit(MSR_EFER, _EFER_AUTOIBRS);
+	}
+
+	if (spectre_v2_in_ibrs_mode(spectre_v2_enabled) &&
+	    !(boot_cpu_has(X86_FEATURE_AUTOIBRS) &&
+	      spectre_v2_in_eibrs_mode(spectre_v2_enabled))) {
+		x86_spec_ctrl_base |= SPEC_CTRL_IBRS;
+		update_spec_ctrl(x86_spec_ctrl_base);
 	}
 
 	if (spectre_v2_in_eibrs_mode(spectre_v2_enabled) &&
-- 
2.43.0

[PATCH v4 05/10] KVM: SEV: Define SVM_SEV_FEAT_* flags using BIT_ULL()

[Kim Phillips]

The VMSA's SEV_FEATURES field is 64 bits wide: struct sev_es_save_area's
sev_features is u64, as are the VMCB allowed_sev_features/guest_sev_features
controls and KVM's vmsa_features / sev_supported_vmsa_features tracking.
Define the SVM_SEV_FEAT_* flags with BIT_ULL() instead of BIT() to match
that width.

No functional change on x86-64, where unsigned long is already 64 bits and
every flag defined today is below bit 32.  It makes the flag type match the
architectural field, keeps composite masks such as the upcoming
SVM_SEV_FEAT_SNP_ONLY_MASK 64-bit, and avoids a latent trap should a future
flag land above bit 31.  The adjacent VMCB_ALLOWED_SEV_FEATURES_VALID
already uses BIT_ULL(63).

Signed-off-by: Kim Phillips <kim.phillips@amd.com>
Assisted-by: ClaudeCode:claude-opus-4-7
---
 arch/x86/include/asm/svm.h | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/x86/include/asm/svm.h b/arch/x86/include/asm/svm.h
index aa63431ba92c..52c900bf7e20 100644
--- a/arch/x86/include/asm/svm.h
+++ b/arch/x86/include/asm/svm.h
@@ -305,11 +305,11 @@ static_assert((AVIC_MAX_PHYSICAL_ID & AVIC_PHYSICAL_MAX_INDEX_MASK) == AVIC_MAX_
 static_assert((X2AVIC_MAX_PHYSICAL_ID & AVIC_PHYSICAL_MAX_INDEX_MASK) == X2AVIC_MAX_PHYSICAL_ID);
 static_assert((X2AVIC_4K_MAX_PHYSICAL_ID & AVIC_PHYSICAL_MAX_INDEX_MASK) == X2AVIC_4K_MAX_PHYSICAL_ID);
 
-#define SVM_SEV_FEAT_SNP_ACTIVE				BIT(0)
-#define SVM_SEV_FEAT_RESTRICTED_INJECTION		BIT(3)
-#define SVM_SEV_FEAT_ALTERNATE_INJECTION		BIT(4)
-#define SVM_SEV_FEAT_DEBUG_SWAP				BIT(5)
-#define SVM_SEV_FEAT_SECURE_TSC				BIT(9)
+#define SVM_SEV_FEAT_SNP_ACTIVE				BIT_ULL(0)
+#define SVM_SEV_FEAT_RESTRICTED_INJECTION		BIT_ULL(3)
+#define SVM_SEV_FEAT_ALTERNATE_INJECTION		BIT_ULL(4)
+#define SVM_SEV_FEAT_DEBUG_SWAP				BIT_ULL(5)
+#define SVM_SEV_FEAT_SECURE_TSC				BIT_ULL(9)
 
 #define VMCB_ALLOWED_SEV_FEATURES_VALID			BIT_ULL(63)
 
-- 
2.43.0

[PATCH v4 06/10] KVM: selftests: sev_init2: Use BIT_ULL for VMSA feature bit definition

[Kim Phillips]

SVM_SEV_FEAT_DEBUG_SWAP was defined as 32u, a 32-bit unsigned literal.
The kernel's supported_vmsa_features is a u64 and uses BIT(5) for this
feature. Redefine the selftest macro with BIT_ULL(5) to match that
64-bit semantic and the BIT_ULL(n) form used by the additional feature
bits introduced later in this series, so every feature-bit definition in
the file is uniformly 64-bit wide. The value is unchanged (0x20); this
is a width/consistency cleanup only.

Signed-off-by: Kim Phillips <kim.phillips@amd.com>
Assisted-by: ClaudeCode:claude-opus-4-7
---
 tools/testing/selftests/kvm/x86/sev_init2_tests.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/testing/selftests/kvm/x86/sev_init2_tests.c b/tools/testing/selftests/kvm/x86/sev_init2_tests.c
index 689390c10f7c..7b0643bf7ca1 100644
--- a/tools/testing/selftests/kvm/x86/sev_init2_tests.c
+++ b/tools/testing/selftests/kvm/x86/sev_init2_tests.c
@@ -13,7 +13,7 @@
 #include "svm_util.h"
 #include "kselftest.h"
 
-#define SVM_SEV_FEAT_DEBUG_SWAP 32u
+#define SVM_SEV_FEAT_DEBUG_SWAP		BIT_ULL(5)
 
 /*
  * Some features may have hidden dependencies, or may only work
-- 
2.43.0

[PATCH v4 07/10] KVM: SEV: Disallow setting SNP-only features for non-SNP guests via a single mask

[Kim Phillips]

As SNP-only features get added, adding them to the valid_vmsa_features mask
in __sev_guest_init() often gets neglected.  Add SVM_SEV_FEAT_SNP_ONLY_MASK
to help group these common features together.

Also establish SNP_ONLY_FEATURES in the sev_init2 selftest as the
corresponding mask for features that must be rejected for non-SNP guests,
populate it with SVM_SEV_FEAT_SECURE_TSC, and exercise the rejection path
by masking those bits out of the features passed for SEV-ES guests.  Define
the selftest's SNP_ONLY_FEATURES as ULL so future bits can use BIT_ULL()
there without truncation against the u64 supported_vmsa_features.

Suggested-by: Sean Christopherson <seanjc@google.com>
Cc: Borislav Petkov (AMD) <bp@alien8.de>
Link: https://lore.kernel.org/kvm/aaWog_UjW-M3412C@google.com/
Signed-off-by: Kim Phillips <kim.phillips@amd.com>
Assisted-by: ClaudeCode:claude-opus-4-7
---
 arch/x86/include/asm/svm.h                        |  2 ++
 arch/x86/kvm/svm/sev.c                            |  2 +-
 tools/testing/selftests/kvm/x86/sev_init2_tests.c | 12 +++++++-----
 3 files changed, 10 insertions(+), 6 deletions(-)

diff --git a/arch/x86/include/asm/svm.h b/arch/x86/include/asm/svm.h
index 52c900bf7e20..a206a0ed2c58 100644
--- a/arch/x86/include/asm/svm.h
+++ b/arch/x86/include/asm/svm.h
@@ -311,6 +311,8 @@ static_assert((X2AVIC_4K_MAX_PHYSICAL_ID & AVIC_PHYSICAL_MAX_INDEX_MASK) == X2AV
 #define SVM_SEV_FEAT_DEBUG_SWAP				BIT_ULL(5)
 #define SVM_SEV_FEAT_SECURE_TSC				BIT_ULL(9)
 
+#define SVM_SEV_FEAT_SNP_ONLY_MASK			(SVM_SEV_FEAT_SECURE_TSC)
+
 #define VMCB_ALLOWED_SEV_FEATURES_VALID			BIT_ULL(63)
 
 struct vmcb_seg {
diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
index 944aaea6501f..951f0e6be9e5 100644
--- a/arch/x86/kvm/svm/sev.c
+++ b/arch/x86/kvm/svm/sev.c
@@ -504,7 +504,7 @@ static int __sev_guest_init(struct kvm *kvm, struct kvm_sev_cmd *argp,
 		return -EINVAL;
 
 	if (!snp_active)
-		valid_vmsa_features &= ~SVM_SEV_FEAT_SECURE_TSC;
+		valid_vmsa_features &= ~SVM_SEV_FEAT_SNP_ONLY_MASK;
 
 	if (data->vmsa_features & ~valid_vmsa_features)
 		return -EINVAL;
diff --git a/tools/testing/selftests/kvm/x86/sev_init2_tests.c b/tools/testing/selftests/kvm/x86/sev_init2_tests.c
index 7b0643bf7ca1..5f4032239f7f 100644
--- a/tools/testing/selftests/kvm/x86/sev_init2_tests.c
+++ b/tools/testing/selftests/kvm/x86/sev_init2_tests.c
@@ -14,16 +14,18 @@
 #include "kselftest.h"
 
 #define SVM_SEV_FEAT_DEBUG_SWAP		BIT_ULL(5)
+#define SVM_SEV_FEAT_SECURE_TSC		BIT_ULL(9)
+
+/* Features valid only for SNP guests, rejected for SEV-ES and below. */
+#define SNP_ONLY_FEATURES		(SVM_SEV_FEAT_SECURE_TSC)
 
 /*
  * Some features may have hidden dependencies, or may only work
  * for certain VM types.  Err on the side of safety and don't
  * expect that all supported features can be passed one by one
  * to KVM_SEV_INIT2.
- *
- * (Well, right now there's only one...)
  */
-#define KNOWN_FEATURES SVM_SEV_FEAT_DEBUG_SWAP
+#define KNOWN_FEATURES		(SVM_SEV_FEAT_DEBUG_SWAP | SNP_ONLY_FEATURES)
 
 int kvm_fd;
 u64 supported_vmsa_features;
@@ -112,7 +114,7 @@ void test_features(u32 vm_type, u64 supported_features)
 		if (!(supported_features & BIT_ULL(i)))
 			test_init2_invalid(vm_type,
 				&(struct kvm_sev_init){ .vmsa_features = BIT_ULL(i) },
-				"unknown feature");
+				"unknown or unsupported feature for VM type");
 		else if (KNOWN_FEATURES & BIT_ULL(i))
 			test_init2(vm_type,
 				&(struct kvm_sev_init){ .vmsa_features = BIT_ULL(i) });
@@ -161,7 +163,7 @@ int main(int argc, char *argv[])
 
 	test_features(KVM_X86_SEV_VM, 0);
 	if (have_sev_es)
-		test_features(KVM_X86_SEV_ES_VM, supported_vmsa_features);
+		test_features(KVM_X86_SEV_ES_VM, supported_vmsa_features & ~SNP_ONLY_FEATURES);
 	if (have_snp)
 		test_features(KVM_X86_SNP_VM, supported_vmsa_features);
 
-- 
2.43.0

[PATCH v4 08/10] KVM: SEV: Advertise SVM_SEV_FEAT_SNP_ACTIVE

[Kim Phillips]

Allow userspace to set the feature in kvm_sev_init.vmsa_features.

KVM still needs to set the flag for backwards compatibility, but
disallowing SVM_SEV_FEAT_SNP_ACTIVE for an SNP guest is "bizarre."

Suggested-by: Sean Christopherson <seanjc@google.com>
Cc: Borislav Petkov (AMD) <bp@alien8.de>
Link: https://lore.kernel.org/kvm/aaWog_UjW-M3412C@google.com/
Signed-off-by: Kim Phillips <kim.phillips@amd.com>
Assisted-by: ClaudeCode:claude-opus-4-7
---
 arch/x86/include/asm/svm.h                        | 3 ++-
 arch/x86/kvm/svm/sev.c                            | 8 ++++++--
 tools/testing/selftests/kvm/x86/sev_init2_tests.c | 4 +++-
 3 files changed, 11 insertions(+), 4 deletions(-)

diff --git a/arch/x86/include/asm/svm.h b/arch/x86/include/asm/svm.h
index a206a0ed2c58..facabba26a91 100644
--- a/arch/x86/include/asm/svm.h
+++ b/arch/x86/include/asm/svm.h
@@ -311,7 +311,8 @@ static_assert((X2AVIC_4K_MAX_PHYSICAL_ID & AVIC_PHYSICAL_MAX_INDEX_MASK) == X2AV
 #define SVM_SEV_FEAT_DEBUG_SWAP				BIT_ULL(5)
 #define SVM_SEV_FEAT_SECURE_TSC				BIT_ULL(9)
 
-#define SVM_SEV_FEAT_SNP_ONLY_MASK			(SVM_SEV_FEAT_SECURE_TSC)
+#define SVM_SEV_FEAT_SNP_ONLY_MASK	(SVM_SEV_FEAT_SNP_ACTIVE | \
+					 SVM_SEV_FEAT_SECURE_TSC)
 
 #define VMCB_ALLOWED_SEV_FEATURES_VALID			BIT_ULL(63)
 
diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
index 951f0e6be9e5..6baf458383f4 100644
--- a/arch/x86/kvm/svm/sev.c
+++ b/arch/x86/kvm/svm/sev.c
@@ -3219,8 +3219,12 @@ void __init sev_hardware_setup(void)
 	    cpu_feature_enabled(X86_FEATURE_NO_NESTED_DATA_BP))
 		sev_supported_vmsa_features |= SVM_SEV_FEAT_DEBUG_SWAP;
 
-	if (sev_snp_enabled && tsc_khz && cpu_feature_enabled(X86_FEATURE_SNP_SECURE_TSC))
-		sev_supported_vmsa_features |= SVM_SEV_FEAT_SECURE_TSC;
+	if (sev_snp_enabled) {
+		sev_supported_vmsa_features |= SVM_SEV_FEAT_SNP_ACTIVE;
+
+		if (tsc_khz && cpu_feature_enabled(X86_FEATURE_SNP_SECURE_TSC))
+			sev_supported_vmsa_features |= SVM_SEV_FEAT_SECURE_TSC;
+	}
 }
 
 void sev_hardware_unsetup(void)
diff --git a/tools/testing/selftests/kvm/x86/sev_init2_tests.c b/tools/testing/selftests/kvm/x86/sev_init2_tests.c
index 5f4032239f7f..2e016cae4ebe 100644
--- a/tools/testing/selftests/kvm/x86/sev_init2_tests.c
+++ b/tools/testing/selftests/kvm/x86/sev_init2_tests.c
@@ -13,11 +13,13 @@
 #include "svm_util.h"
 #include "kselftest.h"
 
+#define SVM_SEV_FEAT_SNP_ACTIVE		BIT_ULL(0)
 #define SVM_SEV_FEAT_DEBUG_SWAP		BIT_ULL(5)
 #define SVM_SEV_FEAT_SECURE_TSC		BIT_ULL(9)
 
 /* Features valid only for SNP guests, rejected for SEV-ES and below. */
-#define SNP_ONLY_FEATURES		(SVM_SEV_FEAT_SECURE_TSC)
+#define SNP_ONLY_FEATURES		(SVM_SEV_FEAT_SNP_ACTIVE | \
+					 SVM_SEV_FEAT_SECURE_TSC)
 
 /*
  * Some features may have hidden dependencies, or may only work
-- 
2.43.0

[PATCH v4 09/10] KVM: SEV: Add support for IBPB-on-Entry

[Kim Phillips]

AMD EPYC 5th generation and above processors support IBPB-on-Entry
for SNP guests.  By invoking an Indirect Branch Prediction Barrier
(IBPB) on VMRUN, old indirect branch predictions are prevented
from influencing indirect branches within the guest.

SNP guests may choose to enable IBPB-on-Entry by setting
SEV_FEATURES bit 21 (IbpbOnEntry).

Host support for IBPB on Entry is indicated by CPUID
Fn8000_001F_EAX[IbpbOnEntry], bit 31.

If supported, indicate support for IBPB on Entry in
sev_supported_vmsa_features bit 21 (IbpbOnEntry).

Also add SVM_SEV_FEAT_IBPB_ON_ENTRY to the sev_init2 selftest's
SNP_ONLY_FEATURES and KNOWN_FEATURES to validate it is accepted
for SNP guests and rejected for SEV-ES.

For more info, refer to page 615, Section 15.36.17 "Side-Channel
Protection", AMD64 Architecture Programmer's Manual Volume 2: System
Programming Part 2, Pub. 24593 Rev. 3.42 - March 2024 (see Link).

Link: https://bugzilla.kernel.org/attachment.cgi?id=306250
Cc: Sean Christopherson <seanjc@google.com>
Cc: Borislav Petkov (AMD) <bp@alien8.de>
Signed-off-by: Kim Phillips <kim.phillips@amd.com>
Assisted-by: ClaudeCode:claude-opus-4-7
---
 arch/x86/include/asm/cpufeatures.h                | 1 +
 arch/x86/include/asm/svm.h                        | 4 +++-
 arch/x86/kvm/svm/sev.c                            | 3 +++
 tools/arch/x86/include/asm/cpufeatures.h          | 1 +
 tools/testing/selftests/kvm/x86/sev_init2_tests.c | 4 +++-
 5 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/arch/x86/include/asm/cpufeatures.h b/arch/x86/include/asm/cpufeatures.h
index 3d0940a3b9f3..11e40644b967 100644
--- a/arch/x86/include/asm/cpufeatures.h
+++ b/arch/x86/include/asm/cpufeatures.h
@@ -460,6 +460,7 @@
 #define X86_FEATURE_ALLOWED_SEV_FEATURES (19*32+27) /* Allowed SEV Features */
 #define X86_FEATURE_SVSM		(19*32+28) /* "svsm" SVSM present */
 #define X86_FEATURE_HV_INUSE_WR_ALLOWED	(19*32+30) /* Allow Write to in-use hypervisor-owned pages */
+#define X86_FEATURE_SNP_IBPB_ON_ENTRY	(19*32+31) /* SEV-SNP IBPB on VM Entry */
 
 /* AMD-defined Extended Feature 2 EAX, CPUID level 0x80000021 (EAX), word 20 */
 #define X86_FEATURE_NO_NESTED_DATA_BP	(20*32+ 0) /* No Nested Data Breakpoints */
diff --git a/arch/x86/include/asm/svm.h b/arch/x86/include/asm/svm.h
index facabba26a91..9d8107824d10 100644
--- a/arch/x86/include/asm/svm.h
+++ b/arch/x86/include/asm/svm.h
@@ -310,9 +310,11 @@ static_assert((X2AVIC_4K_MAX_PHYSICAL_ID & AVIC_PHYSICAL_MAX_INDEX_MASK) == X2AV
 #define SVM_SEV_FEAT_ALTERNATE_INJECTION		BIT_ULL(4)
 #define SVM_SEV_FEAT_DEBUG_SWAP				BIT_ULL(5)
 #define SVM_SEV_FEAT_SECURE_TSC				BIT_ULL(9)
+#define SVM_SEV_FEAT_IBPB_ON_ENTRY			BIT_ULL(21)
 
 #define SVM_SEV_FEAT_SNP_ONLY_MASK	(SVM_SEV_FEAT_SNP_ACTIVE | \
-					 SVM_SEV_FEAT_SECURE_TSC)
+					 SVM_SEV_FEAT_SECURE_TSC | \
+					 SVM_SEV_FEAT_IBPB_ON_ENTRY)
 
 #define VMCB_ALLOWED_SEV_FEATURES_VALID			BIT_ULL(63)
 
diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
index 6baf458383f4..85a692840886 100644
--- a/arch/x86/kvm/svm/sev.c
+++ b/arch/x86/kvm/svm/sev.c
@@ -3224,6 +3224,9 @@ void __init sev_hardware_setup(void)
 
 		if (tsc_khz && cpu_feature_enabled(X86_FEATURE_SNP_SECURE_TSC))
 			sev_supported_vmsa_features |= SVM_SEV_FEAT_SECURE_TSC;
+
+		if (cpu_feature_enabled(X86_FEATURE_SNP_IBPB_ON_ENTRY))
+			sev_supported_vmsa_features |= SVM_SEV_FEAT_IBPB_ON_ENTRY;
 	}
 }
 
diff --git a/tools/arch/x86/include/asm/cpufeatures.h b/tools/arch/x86/include/asm/cpufeatures.h
index 3d0940a3b9f3..11e40644b967 100644
--- a/tools/arch/x86/include/asm/cpufeatures.h
+++ b/tools/arch/x86/include/asm/cpufeatures.h
@@ -460,6 +460,7 @@
 #define X86_FEATURE_ALLOWED_SEV_FEATURES (19*32+27) /* Allowed SEV Features */
 #define X86_FEATURE_SVSM		(19*32+28) /* "svsm" SVSM present */
 #define X86_FEATURE_HV_INUSE_WR_ALLOWED	(19*32+30) /* Allow Write to in-use hypervisor-owned pages */
+#define X86_FEATURE_SNP_IBPB_ON_ENTRY	(19*32+31) /* SEV-SNP IBPB on VM Entry */
 
 /* AMD-defined Extended Feature 2 EAX, CPUID level 0x80000021 (EAX), word 20 */
 #define X86_FEATURE_NO_NESTED_DATA_BP	(20*32+ 0) /* No Nested Data Breakpoints */
diff --git a/tools/testing/selftests/kvm/x86/sev_init2_tests.c b/tools/testing/selftests/kvm/x86/sev_init2_tests.c
index 2e016cae4ebe..ff4322a940c6 100644
--- a/tools/testing/selftests/kvm/x86/sev_init2_tests.c
+++ b/tools/testing/selftests/kvm/x86/sev_init2_tests.c
@@ -16,10 +16,12 @@
 #define SVM_SEV_FEAT_SNP_ACTIVE		BIT_ULL(0)
 #define SVM_SEV_FEAT_DEBUG_SWAP		BIT_ULL(5)
 #define SVM_SEV_FEAT_SECURE_TSC		BIT_ULL(9)
+#define SVM_SEV_FEAT_IBPB_ON_ENTRY	BIT_ULL(21)
 
 /* Features valid only for SNP guests, rejected for SEV-ES and below. */
 #define SNP_ONLY_FEATURES		(SVM_SEV_FEAT_SNP_ACTIVE | \
-					 SVM_SEV_FEAT_SECURE_TSC)
+					 SVM_SEV_FEAT_SECURE_TSC | \
+					 SVM_SEV_FEAT_IBPB_ON_ENTRY)
 
 /*
  * Some features may have hidden dependencies, or may only work
-- 
2.43.0

[PATCH v4 10/10] KVM: SEV: Add support for SNP BTB Isolation

[Kim Phillips]

Advertise support for BTB Isolation via SEV_VMSA_FEATURES when SNP is
enabled.  BTB Isolation is an optional feature that can be enabled by the
guest to ensure its guest Branch Target Buffers (BTBs) are not affected
by any context outside that guest.

SNP-active guests may choose to enable the Branch Target Buffer
Isolation mode through SEV_FEATURES bit 7 (BTBIsolation).

Unlike the sibling features advertised here (Secure TSC, IBPB-on-Entry),
BTB Isolation is advertised unconditionally.  This is deliberate, not an
oversight: the AMD64 APM (Vol. 2, Section 15.36.17 "Side-Channel
Protection") defines BTB Isolation as architecturally present on every
SEV-SNP-capable processor.  There is therefore no host enumeration bit
for it (no CPUID leaf or MSR capability), by design -- unlike
IBPB-on-Entry, whose host support is enumerated via
CPUID Fn8000_001F[IbpbOnEntry] bit 31 precisely because it is not
universal.  A per-feature host gate is thus neither possible nor
meaningful; if SNP is supported, BTB Isolation is present.

Also add SVM_SEV_FEAT_BTB_ISOLATION to the sev_init2 selftest's
SNP_ONLY_FEATURES and KNOWN_FEATURES to validate it is accepted
for SNP guests and rejected for SEV-ES.

For more info, refer to page 615, Section 15.36.17 "Side-Channel
Protection", AMD64 Architecture Programmer's Manual Volume 2: System
Programming Part 2, Pub. 24593 Rev. 3.42 - March 2024 (see Link).

Link: https://bugzilla.kernel.org/attachment.cgi?id=306250
Cc: Sean Christopherson <seanjc@google.com>
Cc: Borislav Petkov (AMD) <bp@alien8.de>
Signed-off-by: Kim Phillips <kim.phillips@amd.com>
Assisted-by: ClaudeCode:claude-opus-4-7
---
 arch/x86/include/asm/svm.h                        | 2 ++
 arch/x86/kvm/svm/sev.c                            | 7 ++++++-
 tools/testing/selftests/kvm/x86/sev_init2_tests.c | 2 ++
 3 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/svm.h b/arch/x86/include/asm/svm.h
index 9d8107824d10..0da2234b71c6 100644
--- a/arch/x86/include/asm/svm.h
+++ b/arch/x86/include/asm/svm.h
@@ -309,10 +309,12 @@ static_assert((X2AVIC_4K_MAX_PHYSICAL_ID & AVIC_PHYSICAL_MAX_INDEX_MASK) == X2AV
 #define SVM_SEV_FEAT_RESTRICTED_INJECTION		BIT_ULL(3)
 #define SVM_SEV_FEAT_ALTERNATE_INJECTION		BIT_ULL(4)
 #define SVM_SEV_FEAT_DEBUG_SWAP				BIT_ULL(5)
+#define SVM_SEV_FEAT_BTB_ISOLATION			BIT_ULL(7)
 #define SVM_SEV_FEAT_SECURE_TSC				BIT_ULL(9)
 #define SVM_SEV_FEAT_IBPB_ON_ENTRY			BIT_ULL(21)
 
 #define SVM_SEV_FEAT_SNP_ONLY_MASK	(SVM_SEV_FEAT_SNP_ACTIVE | \
+					 SVM_SEV_FEAT_BTB_ISOLATION | \
 					 SVM_SEV_FEAT_SECURE_TSC | \
 					 SVM_SEV_FEAT_IBPB_ON_ENTRY)
 
diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
index 85a692840886..ee14795a20bd 100644
--- a/arch/x86/kvm/svm/sev.c
+++ b/arch/x86/kvm/svm/sev.c
@@ -3220,7 +3220,12 @@ void __init sev_hardware_setup(void)
 		sev_supported_vmsa_features |= SVM_SEV_FEAT_DEBUG_SWAP;
 
 	if (sev_snp_enabled) {
-		sev_supported_vmsa_features |= SVM_SEV_FEAT_SNP_ACTIVE;
+		/*
+		 * Some SNP-only features such as BTB Isolation are
+		 * available on all systems that support SNP.
+		 */
+		sev_supported_vmsa_features |= SVM_SEV_FEAT_SNP_ACTIVE |
+					       SVM_SEV_FEAT_BTB_ISOLATION;
 
 		if (tsc_khz && cpu_feature_enabled(X86_FEATURE_SNP_SECURE_TSC))
 			sev_supported_vmsa_features |= SVM_SEV_FEAT_SECURE_TSC;
diff --git a/tools/testing/selftests/kvm/x86/sev_init2_tests.c b/tools/testing/selftests/kvm/x86/sev_init2_tests.c
index ff4322a940c6..cf21bfffacb6 100644
--- a/tools/testing/selftests/kvm/x86/sev_init2_tests.c
+++ b/tools/testing/selftests/kvm/x86/sev_init2_tests.c
@@ -15,11 +15,13 @@
 
 #define SVM_SEV_FEAT_SNP_ACTIVE		BIT_ULL(0)
 #define SVM_SEV_FEAT_DEBUG_SWAP		BIT_ULL(5)
+#define SVM_SEV_FEAT_BTB_ISOLATION	BIT_ULL(7)
 #define SVM_SEV_FEAT_SECURE_TSC		BIT_ULL(9)
 #define SVM_SEV_FEAT_IBPB_ON_ENTRY	BIT_ULL(21)
 
 /* Features valid only for SNP guests, rejected for SEV-ES and below. */
 #define SNP_ONLY_FEATURES		(SVM_SEV_FEAT_SNP_ACTIVE | \
+					 SVM_SEV_FEAT_BTB_ISOLATION | \
 					 SVM_SEV_FEAT_SECURE_TSC | \
 					 SVM_SEV_FEAT_IBPB_ON_ENTRY)
 
-- 
2.43.0