Revoke supported SEV VM types

PATCH In review Tycho Andersen 3 participants 8 messages Mar 24 – Aug 13

Subsystems (7)

x86 KVM Kselftest Crypto API +3 more subsystems

lore

Share & tools

lore

Tycho Andersen

author

2026-03-24 19:41 UTC #0 lore raw

v2 cover Revoke supported SEV VM types

From: "Tycho Andersen (AMD)" <[email protected]>

Recent SEV firmware [1] does not support SEV-ES VMs when SNP is enabled. Expose this by revoking VM-types that are not supported by the current configurations either from firmware restrictions or ASID configuration.

My previous version of this patch series [2] used SNP_VERIFY_MITIGATION to test for a mitigation bit. While AMD-SB-3023 says that there is a mitigation bit (3) for CVE-2025-48514, bit 3 corresponds to an unrelated issue. The correct way to check for this is to use the SVN/SPL from the TCB. We are in the process of updating the SB to reflect this.

changelog from v1:
* compare SVN as above
* fix commit message prefixes
* supported_vm_types local is a u32
* move crypto stuff before KVM stuff in the event of patch tetris

[1]: https://www.amd.com/en/resources/product-security/bulletin/amd-sb-3023.html
[2]: https://lore.kernel.org/all/[email protected]/

Tycho Andersen (AMD) (5):
crypto/ccp: hoist kernel part of SNP_PLATFORM_STATUS crypto/ccp: export firmware supported vm types
KVM: SEV: don't expose unusable VM types
KVM: SEV: mask off firmware unsupported vm types
KVM: selftests: teach sev_*_test about revoking VM types

 arch/x86/kvm/svm/sev.c                        |  15 ++-
 drivers/crypto/ccp/sev-dev.c                  | 101 ++++++++++++++++--
 include/linux/psp-sev.h                       |  37 +++++++
 .../selftests/kvm/x86/sev_init2_tests.c       |  14 ++-
 .../selftests/kvm/x86/sev_migrate_tests.c     |   2 +-
 .../selftests/kvm/x86/sev_smoke_test.c        |   4 +-
 6 files changed, 151 insertions(+), 22 deletions(-)

base-commit: c369299895a591d96745d6492d4888259b004a9e

Signature · 1 line

2.53.0

Tycho Andersen

author

2026-03-24 19:42 UTC #1 lore raw

PATCH v2 1/5 crypto/ccp: hoist kernel part of SNP_PLATFORM_STATUS

From: "Tycho Andersen (AMD)" <[email protected]>

...to its own function. This way it can be used when the kernel needs access to the platform status regardless of the INIT state of the firmware.

No functional change intended.

Signed-off-by Tycho Andersen (AMD) <[email protected]>

---
 drivers/crypto/ccp/sev-dev.c | 31 +++++++++++++++++++++++--------
 1 file changed, 23 insertions(+), 8 deletions(-)

drivers/crypto/ccp/sev-dev.c +23 -8

index aebf4dad545e..64fc402f58df 100644
@@ -2367,7 +2367,8 @@ static int sev_ioctl_do_pdh_export(struct sev_issue_cmd *argp, bool writable)
 	return ret;
 }
 
-static int sev_ioctl_do_snp_platform_status(struct sev_issue_cmd *argp)
+static int __sev_do_snp_platform_status(struct sev_user_data_snp_status *status,
+					int *error)
 {
 	struct sev_device *sev = psp_master->sev_data;
 	struct sev_data_snp_addr buf;

@@ -2375,9 +2376,6 @@ static int sev_ioctl_do_snp_platform_status(struct sev_issue_cmd *argp)
 	void *data;
 	int ret;
 
-	if (!argp->data)
-		return -EINVAL;
-
 	status_page = alloc_page(GFP_KERNEL_ACCOUNT);
 	if (!status_page)
 		return -ENOMEM;

@@ -2400,7 +2398,7 @@ static int sev_ioctl_do_snp_platform_status(struct sev_issue_cmd *argp)
 	}
 
 	buf.address = __psp_pa(data);
-	ret = __sev_do_cmd_locked(SEV_CMD_SNP_PLATFORM_STATUS, &buf, &argp->error);
+	ret = __sev_do_cmd_locked(SEV_CMD_SNP_PLATFORM_STATUS, &buf, error);
 
 	if (sev->snp_initialized) {
 		/*

@@ -2415,15 +2413,32 @@ static int sev_ioctl_do_snp_platform_status(struct sev_issue_cmd *argp)
 	if (ret)
 		goto cleanup;
 
-	if (copy_to_user((void __user *)argp->data, data,
-			 sizeof(struct sev_user_data_snp_status)))
-		ret = -EFAULT;
+	memcpy(status, data, sizeof(*status));
 
 cleanup:
 	__free_pages(status_page, 0);
 	return ret;
 }
 
+static int sev_ioctl_do_snp_platform_status(struct sev_issue_cmd *argp)
+{
+	struct sev_user_data_snp_status status;
+	int ret;
+
+	if (!argp->data)
+		return -EINVAL;
+
+	ret = __sev_do_snp_platform_status(&status, &argp->error);
+	if (ret < 0)
+		return ret;
+
+	if (copy_to_user((void __user *)argp->data, &status,
+			 sizeof(struct sev_user_data_snp_status)))
+		ret = -EFAULT;
+
+	return ret;
+}
+
 static int sev_ioctl_do_snp_commit(struct sev_issue_cmd *argp)
 {
 	struct sev_device *sev = psp_master->sev_data;

Signature · 1 line

2.53.0

Tycho Andersen

author

2026-03-24 19:42 UTC #2 lore raw

PATCH v2 2/5 crypto/ccp: export firmware supported vm types

In reply to Tycho Andersen

From: "Tycho Andersen (AMD)" <[email protected]>

In some configurations, the firmware does not support all VM types. The SEV firmware has an entry in the TCB_VERSION structure referred to as the Security Version Number in the SEV-SNP firmware specification and referred to as the "SPL" in SEV firmware release notes. The SEV firmware release notes say:

On every SEV firmware release where a security mitigation has been added, the SNP SPL gets increased by 1. This is to let users know that it is important to update to this version.

The SEV firmware release that fixed CVE-2025-48514 by disabling SEV-ES support on vulnerable platforms has this SVN increased to reflect the fix. The SVN is platform-specific, as is the structure of TCB_VERSION.

Check CURRENT_TCB instead of REPORTED_TCB, since the firmware behaves with the CURRENT_TCB SVN level and will reject SEV-ES VMs accordingly.

Parse the SVN, and mask off the SEV_ES supported VM type from the list of supported types if it is above the per-platform threshold for the relevant platforms.

Signed-off-by Tycho Andersen (AMD) <[email protected]>

---
 drivers/crypto/ccp/sev-dev.c | 70 ++++++++++++++++++++++++++++++++++++
 include/linux/psp-sev.h      | 37 +++++++++++++++++++
 2 files changed, 107 insertions(+)

drivers/crypto/ccp/sev-dev.c +70 -0

index 64fc402f58df..1e3286c048fe 100644
@@ -2940,3 +2940,73 @@ void sev_pci_exit(void)
 
 	sev_firmware_shutdown(sev);
 }
+
+static int get_v1_svn(struct sev_device *sev)
+{
+	struct sev_snp_tcb_version_genoa_milan *tcb;
+	struct sev_user_data_snp_status status;
+	int ret, error = 0;
+
+	mutex_lock(&sev_cmd_mutex);
+	ret = __sev_do_snp_platform_status(&status, &error);
+	mutex_unlock(&sev_cmd_mutex);
+	if (ret < 0)
+		return ret;
+
+	tcb = (struct sev_snp_tcb_version_genoa_milan *)&status
+		      .current_tcb_version;
+	return tcb->snp;
+}
+
+static int get_v2_svn(struct sev_device *sev)
+{
+	struct sev_user_data_snp_status status;
+	struct sev_snp_tcb_version_turin *tcb;
+	int ret, error = 0;
+
+	mutex_lock(&sev_cmd_mutex);
+	ret = __sev_do_snp_platform_status(&status, &error);
+	mutex_unlock(&sev_cmd_mutex);
+	if (ret < 0)
+		return ret;
+
+	tcb = (struct sev_snp_tcb_version_turin *)&status
+		      .current_tcb_version;
+	return tcb->snp;
+}
+
+static bool sev_firmware_allows_es(struct sev_device *sev)
+{
+	/* Documented in AMD-SB-3023 */
+	if (boot_cpu_has(X86_FEATURE_ZEN4) || boot_cpu_has(X86_FEATURE_ZEN3))
+		return get_v1_svn(sev) < 0x1b;
+	else if (boot_cpu_has(X86_FEATURE_ZEN5))
+		return get_v2_svn(sev) < 0x4;
+	else
+		return true;
+}
+
+int sev_firmware_supported_vm_types(void)
+{
+	int supported_vm_types = 0;
+	struct sev_device *sev;
+
+	if (!psp_master || !psp_master->sev_data)
+		return supported_vm_types;
+	sev = psp_master->sev_data;
+
+	supported_vm_types |= BIT(KVM_X86_SEV_VM);
+	supported_vm_types |= BIT(KVM_X86_SEV_ES_VM);
+
+	if (!sev->snp_initialized)
+		return supported_vm_types;
+
+	supported_vm_types |= BIT(KVM_X86_SNP_VM);
+
+	if (!sev_firmware_allows_es(sev))
+		supported_vm_types &= ~BIT(KVM_X86_SEV_ES_VM);
+
+	return supported_vm_types;
+
+}
+EXPORT_SYMBOL_FOR_MODULES(sev_firmware_supported_vm_types, "kvm-amd");

include/linux/psp-sev.h +37 -0

index 69ffa4b4d1fa..383a682e94fd 100644
@@ -899,6 +899,42 @@ struct snp_feature_info {
 /* Feature bits in EBX */
 #define SNP_SEV_TIO_SUPPORTED			BIT(1)
 
+/**
+ * struct sev_snp_tcb_version_genoa_milan
+ *
+ * @boot_loader: SVN of PSP bootloader
+ * @tee: SVN of PSP operating system
+ * @reserved: reserved
+ * @snp: SVN of SNP firmware
+ * @microcode: Lowest current patch level of all cores
+ */
+struct sev_snp_tcb_version_genoa_milan {
+	u8 boot_loader;
+	u8 tee;
+	u8 reserved[4];
+	u8 snp;
+	u8 microcode;
+};
+
+/**
+ * struct sev_snp_tcb_version_turin
+ *
+ * @fmc: SVN of FMC firmware
+ * @boot_loader: SVN of PSP bootloader
+ * @tee: SVN of PSP operating system
+ * @snp: SVN of SNP firmware
+ * @reserved: reserved
+ * @microcode: Lowest current patch level of all cores
+ */
+struct sev_snp_tcb_version_turin {
+	u8 fmc;
+	u8 boot_loader;
+	u8 tee;
+	u8 snp;
+	u8 reserved[3];
+	u8 microcode;
+};
+
 #ifdef CONFIG_CRYPTO_DEV_SP_PSP
 
 /**

@@ -1045,6 +1081,7 @@ void snp_free_firmware_page(void *addr);
 void sev_platform_shutdown(void);
 bool sev_is_snp_ciphertext_hiding_supported(void);
 u64 sev_get_snp_policy_bits(void);
+int sev_firmware_supported_vm_types(void);
 
 #else	/* !CONFIG_CRYPTO_DEV_SP_PSP */

Signature · 1 line

2.53.0

Tycho Andersen

author

2026-03-24 19:42 UTC #3 lore raw

PATCH v2 3/5 KVM: SEV: don't expose unusable VM types

In reply to Tycho Andersen

From: "Tycho Andersen (AMD)" <[email protected]>

Commit 0aa6b90ef9d7 ("KVM: SVM: Add support for allowing zero SEV ASIDs") made it possible to make it impossible to use SEV VMs by not allocating them any ASIDs.

Commit 6c7c620585c6 ("KVM: SEV: Add SEV-SNP CipherTextHiding support") did the same thing for SEV-ES.

Do not export KVM_X86_SEV(_ES)_VM as supported types if in either of these situations, so that userspace can use them to determine what is actually supported by the current kernel configuration.

Also move the buildup to a local variable so it is easier to add additional masking in future patches.

Link https://lore.kernel.org/all/[email protected]/ open here

Signed-off-by Tycho Andersen (AMD) <[email protected]>

---
 arch/x86/kvm/svm/sev.c | 14 +++++++++++---
 1 file changed, 11 insertions(+), 3 deletions(-)

arch/x86/kvm/svm/sev.c +11 -3

index 3f9c1aa39a0a..37490803f2e8 100644
@@ -2957,18 +2957,26 @@ void sev_vm_destroy(struct kvm *kvm)
 
 void __init sev_set_cpu_caps(void)
 {
+	u32 supported_vm_types = 0;
+
 	if (sev_enabled) {
 		kvm_cpu_cap_set(X86_FEATURE_SEV);
-		kvm_caps.supported_vm_types |= BIT(KVM_X86_SEV_VM);
+
+		if (min_sev_asid <= max_sev_asid)
+			supported_vm_types |= BIT(KVM_X86_SEV_VM);
 	}
 	if (sev_es_enabled) {
 		kvm_cpu_cap_set(X86_FEATURE_SEV_ES);
-		kvm_caps.supported_vm_types |= BIT(KVM_X86_SEV_ES_VM);
+
+		if (min_sev_es_asid <= max_sev_es_asid)
+			supported_vm_types |= BIT(KVM_X86_SEV_ES_VM);
 	}
 	if (sev_snp_enabled) {
 		kvm_cpu_cap_set(X86_FEATURE_SEV_SNP);
-		kvm_caps.supported_vm_types |= BIT(KVM_X86_SNP_VM);
+		supported_vm_types |= BIT(KVM_X86_SNP_VM);
 	}
+
+	kvm_caps.supported_vm_types |= supported_vm_types;
 }
 
 static bool is_sev_snp_initialized(void)

Signature · 1 line

2.53.0

Tycho Andersen

author

2026-03-24 19:42 UTC #4 lore raw

PATCH v2 4/5 KVM: SEV: mask off firmware unsupported vm types

In reply to Tycho Andersen

From: "Tycho Andersen (AMD)" <[email protected]>

In some configurations not all VM types are supported by the firmware. Reflect this information in the supported_vm_types that KVM exports.

Link https://lore.kernel.org/all/[email protected]/ open here

Signed-off-by Tycho Andersen (AMD) <[email protected]>

---
 arch/x86/kvm/svm/sev.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

arch/x86/kvm/svm/sev.c +2 -1

index 37490803f2e8..0fe9515db1e7 100644
@@ -2976,7 +2976,8 @@ void __init sev_set_cpu_caps(void)
 		supported_vm_types |= BIT(KVM_X86_SNP_VM);
 	}
 
-	kvm_caps.supported_vm_types |= supported_vm_types;
+	kvm_caps.supported_vm_types |= (supported_vm_types &
+					sev_firmware_supported_vm_types());
 }
 
 static bool is_sev_snp_initialized(void)

Signature · 1 line

2.53.0

Sean Christopherson

maintainer

2026-04-09 21:17 UTC #5 lore raw

Re: [PATCH v2 4/5] KVM: SEV: mask off firmware unsupported vm types

Quoted 17 lines · Tycho Andersen

From: "Tycho Andersen (AMD)" <[email protected]>
In some configurations not all VM types are supported by the firmware. Reflect this information in the supported_vm_types that KVM exports.
Link https://lore.kernel.org/all/[email protected]/ open here
Suggested-by Sean Christopherson <[email protected]>
Signed-off-by Tycho Andersen (AMD) <[email protected]>
---
 arch/x86/kvm/svm/sev.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
arch/x86/kvm/svm/sev.c +0 -0
index 37490803f2e8..0fe9515db1e7 100644

arch/x86/kvm/svm/sev.c void __init sev_set_cpu_caps(void) · line 2980

Quoted 6 lines

arch/x86/kvm/svm/sev.c +2 -1

@@ -2976,7 +2976,8 @@ void __init sev_set_cpu_caps(void)
 		supported_vm_types |= BIT(KVM_X86_SNP_VM);
 	}
 
-	kvm_caps.supported_vm_types |= supported_vm_types;
+	kvm_caps.supported_vm_types |= (supported_vm_types &
+					sev_firmware_supported_vm_types());

This is slightly flawed, in that sev_hardware_setup() still reports SEV-ES as fully enabled, whereas the other cases (ASID exhaustation) clear the VM type *and* report the feature as "unusable".

Addressing that is actually a great opportunity to dedup some code in the previous path. I.e. if we first relocate the supported_vm_types updates to sev_hardware_setup(), then there's no need to copy+paste the ASID checks. And then restricting VM types based on firmware support Just Works.

E.g. to yield:

[ 1813.863571] ccp 0000:24:00.1: SEV-SNP API:1.58 build:1
[ 1813.876790] kvm_amd: SEV enabled (ASIDs 254 - 509)
[ 1813.881595] kvm_amd: SEV-ES unusable (ASIDs 1 - 253)
[ 1813.886574] kvm_amd: SEV-SNP enabled (ASIDs 1 - 253)
[ 1813.891549] kvm_amd: Virtual VMLOAD VMSAVE supported
[ 1813.896522] kvm_amd: Virtual GIF supported

I'll send a v3, I've got everything coded up (I wanted to make sure my idea actually worked before suggesting it :-) ).

Tycho Andersen

author

2026-03-24 19:42 UTC #6 lore raw

PATCH v2 5/5 KVM: selftests: teach sev_*_test about revoking VM types

In reply to Tycho Andersen

From: "Tycho Andersen (AMD)" <[email protected]>

Instead of using CPUID, use the VM type bit to determine support, since those now reflect the correct status of support by the kernel and firmware configurations.

Signed-off-by Tycho Andersen (AMD) <[email protected]>

---
 tools/testing/selftests/kvm/x86/sev_init2_tests.c  | 14 ++++++--------
 .../testing/selftests/kvm/x86/sev_migrate_tests.c  |  2 +-
 tools/testing/selftests/kvm/x86/sev_smoke_test.c   |  4 ++--
 3 files changed, 9 insertions(+), 11 deletions(-)

tools/testing/selftests/kvm/x86/sev_init2_tests.c +6 -8

index b238615196ad..97bd036b4f1c 100644
@@ -136,16 +136,14 @@ int main(int argc, char *argv[])
 		    kvm_check_cap(KVM_CAP_VM_TYPES), 1 << KVM_X86_SEV_VM);
 
 	TEST_REQUIRE(kvm_check_cap(KVM_CAP_VM_TYPES) & BIT(KVM_X86_SEV_VM));
-	have_sev_es = kvm_cpu_has(X86_FEATURE_SEV_ES);
+	have_sev_es = kvm_check_cap(KVM_CAP_VM_TYPES) & BIT(KVM_X86_SEV_ES_VM);
 
-	TEST_ASSERT(have_sev_es == !!(kvm_check_cap(KVM_CAP_VM_TYPES) & BIT(KVM_X86_SEV_ES_VM)),
-		    "sev-es: KVM_CAP_VM_TYPES (%x) does not match cpuid (checking %x)",
-		    kvm_check_cap(KVM_CAP_VM_TYPES), 1 << KVM_X86_SEV_ES_VM);
+	TEST_ASSERT(!have_sev_es || kvm_cpu_has(X86_FEATURE_SEV_ES),
+		    "sev-es: SEV_ES_VM supported without SEV_ES in CPUID");
 
-	have_snp = kvm_cpu_has(X86_FEATURE_SEV_SNP);
-	TEST_ASSERT(have_snp == !!(kvm_check_cap(KVM_CAP_VM_TYPES) & BIT(KVM_X86_SNP_VM)),
-		    "sev-snp: KVM_CAP_VM_TYPES (%x) indicates SNP support (bit %d), but CPUID does not",
-		    kvm_check_cap(KVM_CAP_VM_TYPES), KVM_X86_SNP_VM);
+	have_snp = kvm_check_cap(KVM_CAP_VM_TYPES) & BIT(KVM_X86_SNP_VM);
+	TEST_ASSERT(!have_snp || kvm_cpu_has(X86_FEATURE_SEV_SNP),
+		    "sev-snp: SNP_VM supported without SEV_SNP in CPUID");
 
 	test_vm_types();

tools/testing/selftests/kvm/x86/sev_migrate_tests.c +1 -1

index 0a6dfba3905b..3f2c3b00e3bc 100644
@@ -376,7 +376,7 @@ int main(int argc, char *argv[])
 
 	TEST_REQUIRE(kvm_cpu_has(X86_FEATURE_SEV));
 
-	have_sev_es = kvm_cpu_has(X86_FEATURE_SEV_ES);
+	have_sev_es = kvm_check_cap(KVM_CAP_VM_TYPES) & BIT(KVM_X86_SEV_ES_VM);
 
 	if (kvm_has_cap(KVM_CAP_VM_MOVE_ENC_CONTEXT_FROM)) {
 		test_sev_migrate_from(/* es= */ false);

tools/testing/selftests/kvm/x86/sev_smoke_test.c +2 -2

index 8bd37a476f15..f3c39335ff39 100644
@@ -249,10 +249,10 @@ int main(int argc, char *argv[])
 
 	test_sev_smoke(guest_sev_code, KVM_X86_SEV_VM, 0);
 
-	if (kvm_cpu_has(X86_FEATURE_SEV_ES))
+	if (kvm_check_cap(KVM_CAP_VM_TYPES) & BIT(KVM_X86_SEV_ES_VM))
 		test_sev_smoke(guest_sev_es_code, KVM_X86_SEV_ES_VM, SEV_POLICY_ES);
 
-	if (kvm_cpu_has(X86_FEATURE_SEV_SNP))
+	if (kvm_check_cap(KVM_CAP_VM_TYPES) & BIT(KVM_X86_SNP_VM))
 		test_sev_smoke(guest_snp_code, KVM_X86_SNP_VM, snp_default_policy());
 
 	return 0;

Signature · 1 line

2.53.0

[email protected]

AI review

2026-08-13 22:39 UTC #7 lore raw

Re: [PATCH v2 5/5] KVM: selftests: teach sev_*_test about revoking VM types

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [Medium] The patch updates SEV-ES and SEV-SNP support checks to use KVM_CAP_VM_TYPES instead of CPUID to handle cases where VM types are revoked (e.g., due to ASID exhaustion), but misses applying this logic to basic SEV, leading to test crashes. --

--- Patch [5]: [PATCH v2 5/5] KVM: selftests: teach sev_*_test about revoking VM types --- commit 2ec0ef2342e44224fa7c2705ca4877c7bb8e8605
Author: Tycho Andersen (AMD) <[email protected]>

KVM: selftests: teach sev_*_test about revoking VM types

Updates KVM selftests to use the VM type bit instead of CPUID to determine SEV-ES and SEV-SNP support. This accommodates environments where kernel and firmware configurations revoke VM types.

tools/testing/selftests/kvm/x86/sev_init2_tests.c int main(int argc, char *argv[]) · line 138

Quoted 11 lines

tools/testing/selftests/kvm/x86/sev_init2_tests.c +0 -0

index b238615196ade..97bd036b4f1c5 100644
@@ -133,9 +133,8 @@ int main(int argc, char *argv[])
 	have_sev = kvm_cpu_has(X86_FEATURE_SEV);
 	TEST_ASSERT(have_sev == !!(kvm_check_cap(KVM_CAP_VM_TYPES) & BIT(KVM_X86_SEV_VM)),
 		    "sev: KVM_CAP_VM_TYPES (%x) does not match cpuid (checking %x)",
 		    kvm_check_cap(KVM_CAP_VM_TYPES), 1 << KVM_X86_SEV_VM);
 
 	TEST_REQUIRE(kvm_check_cap(KVM_CAP_VM_TYPES) & BIT(KVM_X86_SEV_VM));

[Severity: Medium]
This isn't a bug introduced by this patch, but does the same logic need to be applied to basic SEV here?

If base SEV ASIDs are exhausted, the kernel revokes KVM_X86_SEV_VM support, but CPUID still advertises X86_FEATURE_SEV. Since this code asserts that CPUID perfectly matches KVM_CAP_VM_TYPES, won't this cause a test crash when they inevitably diverge?

Quoted 2 lines

tools/testing/selftests/kvm/x86/sev_init2_tests.c +1 -1

-	have_sev_es = kvm_cpu_has(X86_FEATURE_SEV_ES);
+	have_sev_es = kvm_check_cap(KVM_CAP_VM_TYPES) & BIT(KVM_X86_SEV_ES_VM);

[ ... ]

tools/testing/selftests/kvm/x86/sev_migrate_tests.c int main(int argc, char *argv[]) · line 375

Quoted 7 lines

tools/testing/selftests/kvm/x86/sev_migrate_tests.c +0 -0

index 0a6dfba3905b6..3f2c3b00e3bc4 100644
@@ -374,7 +374,7 @@ int main(int argc, char *argv[])
 
 	TEST_REQUIRE(kvm_cpu_has(X86_FEATURE_SEV));

[Severity: Medium]
This is a pre-existing issue, but should this TEST_REQUIRE check KVM_CAP_VM_TYPES instead of CPUID?

If the SEV VM type has been revoked, CPUID will still report support, which might lead to crashes upon VM creation when the migration tests execute.

Quoted 5 lines

tools/testing/selftests/kvm/x86/sev_migrate_tests.c +1 -1

-	have_sev_es = kvm_cpu_has(X86_FEATURE_SEV_ES);
+	have_sev_es = kvm_check_cap(KVM_CAP_VM_TYPES) & BIT(KVM_X86_SEV_ES_VM);
 
 	if (kvm_has_cap(KVM_CAP_VM_MOVE_ENC_CONTEXT_FROM)) {
 		test_sev_migrate_from(/* es= */ false);

[ ... ]

tools/testing/selftests/kvm/x86/sev_smoke_test.c int main(int argc, char *argv[]) · line 250

Quoted 9 lines

tools/testing/selftests/kvm/x86/sev_smoke_test.c +0 -0

index 8bd37a476f159..f3c39335ff39a 100644
@@ -247,8 +247,8 @@ int main(int argc, char *argv[])
 {
 	TEST_REQUIRE(kvm_cpu_has(X86_FEATURE_SEV));
 
 	test_sev_smoke(guest_sev_code, KVM_X86_SEV_VM, 0);

[Severity: Medium]
This is a pre-existing issue, but does gating execution on CPUID rather than KVM_CAP_VM_TYPES cause an issue here?

If KVM lacks SEV support despite CPUID, won't it crash when calling test_sev_smoke() for base SEV?

Quoted 3 lines

tools/testing/selftests/kvm/x86/sev_smoke_test.c +1 -1

-	if (kvm_cpu_has(X86_FEATURE_SEV_ES))
+	if (kvm_check_cap(KVM_CAP_VM_TYPES) & BIT(KVM_X86_SEV_ES_VM))
 		test_sev_smoke(guest_sev_es_code, KVM_X86_SEV_ES_VM, SEV_POLICY_ES);

Signature · 1 line

Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=5