[PATCH v3 0/7] KVM: SEV: Don't advertise unusable VM types

[PATCH v3 0/7] KVM: SEV: Don't advertise unusable VM types

[Sean Christopherson]

My preference would be to take this through the KVM tree, with acks on the
crypto patches.  I'd also be a-ok with a stable branch/tag of the crypto
changes.

In the words of Tycho:

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.

v3:
 - Relocate the supported_vm_types updates to sev_hardware_setup.
 - Report unusable VM types as such in dmesg.

v2:
 - https://lore.kernel.org/all/20260324194034.1442133-1-tycho@kernel.org
 - 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/20260303191509.1565629-1-tycho@kernel.org

Sean Christopherson (3):
  KVM: SEV: Set supported SEV+ VM types during sev_hardware_setup()
  KVM: SEV: Consolidate logic for printing state of SEV{,-ES,-SNP}
    enabling
  KVM: SEV: Don't advertise support for unusable VM types

Tycho Andersen (4):
  crypto/ccp: hoist kernel part of SNP_PLATFORM_STATUS
  crypto/ccp: export firmware supported vm types
  KVM: SEV: Don't advertise VM types that are disabled by firmware
  KVM: selftests: Teach sev_*_test about revoking VM types

 arch/x86/kvm/svm/sev.c                        |  40 ++++---
 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, 163 insertions(+), 35 deletions(-)


base-commit: 6b802031877a995456c528095c41d1948546bf45
-- 
2.54.0.rc1.513.gad8abe7a5a-goog

[PATCH v3 1/7] crypto/ccp: hoist kernel part of SNP_PLATFORM_STATUS

[Sean Christopherson]

From: Tycho Andersen <tycho@kernel.org>

...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.

Cc: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Tycho Andersen (AMD) <tycho@kernel.org>
Signed-off-by: Sean Christopherson <seanjc@google.com>
---
 drivers/crypto/ccp/sev-dev.c | 31 +++++++++++++++++++++++--------
 1 file changed, 23 insertions(+), 8 deletions(-)

diff --git a/drivers/crypto/ccp/sev-dev.c b/drivers/crypto/ccp/sev-dev.c
index aebf4dad545e..64fc402f58df 100644
--- a/drivers/crypto/ccp/sev-dev.c
+++ b/drivers/crypto/ccp/sev-dev.c
@@ -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;
-- 
2.54.0.rc1.513.gad8abe7a5a-goog

Re: [PATCH v3 1/7] crypto/ccp: hoist kernel part of SNP_PLATFORM_STATUS

[Tom Lendacky]

On 4/16/26 18:23, Sean Christopherson wrote:
> From: Tycho Andersen <tycho@kernel.org>
> 
> ...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.
> 
> Cc: Herbert Xu <herbert@gondor.apana.org.au>
> Signed-off-by: Tycho Andersen (AMD) <tycho@kernel.org>
> Signed-off-by: Sean Christopherson <seanjc@google.com>

One minor comment below, but not a big deal.

Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>

> ---
>  drivers/crypto/ccp/sev-dev.c | 31 +++++++++++++++++++++++--------
>  1 file changed, 23 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/crypto/ccp/sev-dev.c b/drivers/crypto/ccp/sev-dev.c
> index aebf4dad545e..64fc402f58df 100644
> --- a/drivers/crypto/ccp/sev-dev.c
> +++ b/drivers/crypto/ccp/sev-dev.c
> @@ -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)

Any non-zero value is an error, so this really should just be "if (ret)"

Thanks,
Tom

> +		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;

Re: [PATCH v3 1/7] crypto/ccp: hoist kernel part of SNP_PLATFORM_STATUS

[Herbert Xu]

On Thu, Apr 16, 2026 at 04:23:23PM -0700, Sean Christopherson wrote:
> From: Tycho Andersen <tycho@kernel.org>
> 
> ...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.
> 
> Cc: Herbert Xu <herbert@gondor.apana.org.au>
> Signed-off-by: Tycho Andersen (AMD) <tycho@kernel.org>
> Signed-off-by: Sean Christopherson <seanjc@google.com>
> ---
>  drivers/crypto/ccp/sev-dev.c | 31 +++++++++++++++++++++++--------
>  1 file changed, 23 insertions(+), 8 deletions(-)

Acked-by: Herbert Xu <herbert@gondor.apana.org.au>

Thanks,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

[PATCH v3 2/7] crypto/ccp: export firmware supported vm types

[Sean Christopherson]

From: Tycho Andersen <tycho@kernel.org>

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) <tycho@kernel.org>
Signed-off-by: Sean Christopherson <seanjc@google.com>
---
 drivers/crypto/ccp/sev-dev.c | 70 ++++++++++++++++++++++++++++++++++++
 include/linux/psp-sev.h      | 37 +++++++++++++++++++
 2 files changed, 107 insertions(+)

diff --git a/drivers/crypto/ccp/sev-dev.c b/drivers/crypto/ccp/sev-dev.c
index 64fc402f58df..1e3286c048fe 100644
--- a/drivers/crypto/ccp/sev-dev.c
+++ b/drivers/crypto/ccp/sev-dev.c
@@ -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");
diff --git a/include/linux/psp-sev.h b/include/linux/psp-sev.h
index 69ffa4b4d1fa..383a682e94fd 100644
--- a/include/linux/psp-sev.h
+++ b/include/linux/psp-sev.h
@@ -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 */
 
-- 
2.54.0.rc1.513.gad8abe7a5a-goog

Re: [PATCH v3 2/7] crypto/ccp: export firmware supported vm types

[Tom Lendacky]

On 4/16/26 18:23, Sean Christopherson wrote:
> From: Tycho Andersen <tycho@kernel.org>
> 
> 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) <tycho@kernel.org>
> Signed-off-by: Sean Christopherson <seanjc@google.com>

Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>

> ---
>  drivers/crypto/ccp/sev-dev.c | 70 ++++++++++++++++++++++++++++++++++++
>  include/linux/psp-sev.h      | 37 +++++++++++++++++++
>  2 files changed, 107 insertions(+)
> 
> diff --git a/drivers/crypto/ccp/sev-dev.c b/drivers/crypto/ccp/sev-dev.c
> index 64fc402f58df..1e3286c048fe 100644
> --- a/drivers/crypto/ccp/sev-dev.c
> +++ b/drivers/crypto/ccp/sev-dev.c
> @@ -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");
> diff --git a/include/linux/psp-sev.h b/include/linux/psp-sev.h
> index 69ffa4b4d1fa..383a682e94fd 100644
> --- a/include/linux/psp-sev.h
> +++ b/include/linux/psp-sev.h
> @@ -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 */
>  

Re: [PATCH v3 2/7] crypto/ccp: export firmware supported vm types

[Herbert Xu]

On Thu, Apr 16, 2026 at 04:23:24PM -0700, Sean Christopherson wrote:
> From: Tycho Andersen <tycho@kernel.org>
> 
> 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) <tycho@kernel.org>
> Signed-off-by: Sean Christopherson <seanjc@google.com>
> ---
>  drivers/crypto/ccp/sev-dev.c | 70 ++++++++++++++++++++++++++++++++++++
>  include/linux/psp-sev.h      | 37 +++++++++++++++++++
>  2 files changed, 107 insertions(+)

Acked-by: Herbert Xu <herbert@gondor.apana.org.au>

Thanks,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

[PATCH v3 3/7] KVM: SEV: Set supported SEV+ VM types during sev_hardware_setup()

[Sean Christopherson]

Set the supported SEV+ VM types during sev_hardware_setup() instead of
waiting until sev_set_cpu_caps().  This will using the set of *fully*
supported VM types to print the enabled/unusable/disabled messaged.

For all intents and purposes, no functional change intended.

Signed-off-by: Sean Christopherson <seanjc@google.com>
---
 arch/x86/kvm/svm/sev.c | 21 ++++++++++++---------
 1 file changed, 12 insertions(+), 9 deletions(-)

diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
index c2126b3c3072..ea4ce371d5f3 100644
--- a/arch/x86/kvm/svm/sev.c
+++ b/arch/x86/kvm/svm/sev.c
@@ -3013,18 +3013,14 @@ void sev_vm_destroy(struct kvm *kvm)
 
 void __init sev_set_cpu_caps(void)
 {
-	if (sev_enabled) {
+	if (sev_enabled)
 		kvm_cpu_cap_set(X86_FEATURE_SEV);
-		kvm_caps.supported_vm_types |= BIT(KVM_X86_SEV_VM);
-	}
-	if (sev_es_enabled) {
+
+	if (sev_es_enabled)
 		kvm_cpu_cap_set(X86_FEATURE_SEV_ES);
-		kvm_caps.supported_vm_types |= BIT(KVM_X86_SEV_ES_VM);
-	}
-	if (sev_snp_enabled) {
+
+	if (sev_snp_enabled)
 		kvm_cpu_cap_set(X86_FEATURE_SEV_SNP);
-		kvm_caps.supported_vm_types |= BIT(KVM_X86_SNP_VM);
-	}
 }
 
 static bool is_sev_snp_initialized(void)
@@ -3194,6 +3190,13 @@ void __init sev_hardware_setup(void)
 		}
 	}
 
+	if (sev_supported)
+		kvm_caps.supported_vm_types |= BIT(KVM_X86_SEV_VM);
+	if (sev_es_supported)
+		kvm_caps.supported_vm_types |= BIT(KVM_X86_SEV_ES_VM);
+	if (sev_snp_supported)
+		kvm_caps.supported_vm_types |= BIT(KVM_X86_SNP_VM);
+
 	if (boot_cpu_has(X86_FEATURE_SEV))
 		pr_info("SEV %s (ASIDs %u - %u)\n",
 			sev_supported ? min_sev_asid <= max_sev_asid ? "enabled" :
-- 
2.54.0.rc1.513.gad8abe7a5a-goog

Re: [PATCH v3 3/7] KVM: SEV: Set supported SEV+ VM types during sev_hardware_setup()

[Tom Lendacky]

On 4/16/26 18:23, Sean Christopherson wrote:
> Set the supported SEV+ VM types during sev_hardware_setup() instead of
> waiting until sev_set_cpu_caps().  This will using the set of *fully*
> supported VM types to print the enabled/unusable/disabled messaged.
> 
> For all intents and purposes, no functional change intended.
> 
> Signed-off-by: Sean Christopherson <seanjc@google.com>

Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>

> ---
>  arch/x86/kvm/svm/sev.c | 21 ++++++++++++---------
>  1 file changed, 12 insertions(+), 9 deletions(-)
> 
> diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
> index c2126b3c3072..ea4ce371d5f3 100644
> --- a/arch/x86/kvm/svm/sev.c
> +++ b/arch/x86/kvm/svm/sev.c
> @@ -3013,18 +3013,14 @@ void sev_vm_destroy(struct kvm *kvm)
>  
>  void __init sev_set_cpu_caps(void)
>  {
> -	if (sev_enabled) {
> +	if (sev_enabled)
>  		kvm_cpu_cap_set(X86_FEATURE_SEV);
> -		kvm_caps.supported_vm_types |= BIT(KVM_X86_SEV_VM);
> -	}
> -	if (sev_es_enabled) {
> +
> +	if (sev_es_enabled)
>  		kvm_cpu_cap_set(X86_FEATURE_SEV_ES);
> -		kvm_caps.supported_vm_types |= BIT(KVM_X86_SEV_ES_VM);
> -	}
> -	if (sev_snp_enabled) {
> +
> +	if (sev_snp_enabled)
>  		kvm_cpu_cap_set(X86_FEATURE_SEV_SNP);
> -		kvm_caps.supported_vm_types |= BIT(KVM_X86_SNP_VM);
> -	}
>  }
>  
>  static bool is_sev_snp_initialized(void)
> @@ -3194,6 +3190,13 @@ void __init sev_hardware_setup(void)
>  		}
>  	}
>  
> +	if (sev_supported)
> +		kvm_caps.supported_vm_types |= BIT(KVM_X86_SEV_VM);
> +	if (sev_es_supported)
> +		kvm_caps.supported_vm_types |= BIT(KVM_X86_SEV_ES_VM);
> +	if (sev_snp_supported)
> +		kvm_caps.supported_vm_types |= BIT(KVM_X86_SNP_VM);
> +
>  	if (boot_cpu_has(X86_FEATURE_SEV))
>  		pr_info("SEV %s (ASIDs %u - %u)\n",
>  			sev_supported ? min_sev_asid <= max_sev_asid ? "enabled" :

[PATCH v3 4/7] KVM: SEV: Consolidate logic for printing state of SEV{,-ES,-SNP} enabling

[Sean Christopherson]

Add a helper to print enabled/unusable/disabled for SEV+ VM types in
anticipation of SNP also being subjecting to "unusable" logic.

No functional change intended.

Signed-off-by: Sean Christopherson <seanjc@google.com>
---
 arch/x86/kvm/svm/sev.c | 15 ++++++++-------
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
index ea4ce371d5f3..dfeb660b8f5d 100644
--- a/arch/x86/kvm/svm/sev.c
+++ b/arch/x86/kvm/svm/sev.c
@@ -3050,6 +3050,11 @@ static bool is_sev_snp_initialized(void)
 	return initialized;
 }
 
+static const char * __init sev_str_feature_state(bool is_supported, bool is_usable)
+{
+	return is_supported ? is_usable ? "enabled" : "unusable" : "disabled";
+}
+
 void __init sev_hardware_setup(void)
 {
 	unsigned int eax, ebx, ecx, edx, sev_asid_count, sev_es_asid_count;
@@ -3199,19 +3204,15 @@ void __init sev_hardware_setup(void)
 
 	if (boot_cpu_has(X86_FEATURE_SEV))
 		pr_info("SEV %s (ASIDs %u - %u)\n",
-			sev_supported ? min_sev_asid <= max_sev_asid ? "enabled" :
-								       "unusable" :
-								       "disabled",
+			sev_str_feature_state(sev_supported, min_sev_asid <= max_sev_asid),
 			min_sev_asid, max_sev_asid);
 	if (boot_cpu_has(X86_FEATURE_SEV_ES))
 		pr_info("SEV-ES %s (ASIDs %u - %u)\n",
-			sev_es_supported ? min_sev_es_asid <= max_sev_es_asid ? "enabled" :
-										"unusable" :
-										"disabled",
+			sev_str_feature_state(sev_es_supported, min_sev_es_asid <= max_sev_es_asid),
 			min_sev_es_asid, max_sev_es_asid);
 	if (boot_cpu_has(X86_FEATURE_SEV_SNP))
 		pr_info("SEV-SNP %s (ASIDs %u - %u)\n",
-			str_enabled_disabled(sev_snp_supported),
+			sev_str_feature_state(sev_snp_supported, true),
 			min_snp_asid, max_snp_asid);
 
 	sev_enabled = sev_supported;
-- 
2.54.0.rc1.513.gad8abe7a5a-goog

Re: [PATCH v3 4/7] KVM: SEV: Consolidate logic for printing state of SEV{,-ES,-SNP} enabling

[Tom Lendacky]

On 4/16/26 18:23, Sean Christopherson wrote:
> Add a helper to print enabled/unusable/disabled for SEV+ VM types in
> anticipation of SNP also being subjecting to "unusable" logic.
> 
> No functional change intended.
> 
> Signed-off-by: Sean Christopherson <seanjc@google.com>

Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>

> ---
>  arch/x86/kvm/svm/sev.c | 15 ++++++++-------
>  1 file changed, 8 insertions(+), 7 deletions(-)
> 
> diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
> index ea4ce371d5f3..dfeb660b8f5d 100644
> --- a/arch/x86/kvm/svm/sev.c
> +++ b/arch/x86/kvm/svm/sev.c
> @@ -3050,6 +3050,11 @@ static bool is_sev_snp_initialized(void)
>  	return initialized;
>  }
>  
> +static const char * __init sev_str_feature_state(bool is_supported, bool is_usable)
> +{
> +	return is_supported ? is_usable ? "enabled" : "unusable" : "disabled";
> +}
> +
>  void __init sev_hardware_setup(void)
>  {
>  	unsigned int eax, ebx, ecx, edx, sev_asid_count, sev_es_asid_count;
> @@ -3199,19 +3204,15 @@ void __init sev_hardware_setup(void)
>  
>  	if (boot_cpu_has(X86_FEATURE_SEV))
>  		pr_info("SEV %s (ASIDs %u - %u)\n",
> -			sev_supported ? min_sev_asid <= max_sev_asid ? "enabled" :
> -								       "unusable" :
> -								       "disabled",
> +			sev_str_feature_state(sev_supported, min_sev_asid <= max_sev_asid),
>  			min_sev_asid, max_sev_asid);
>  	if (boot_cpu_has(X86_FEATURE_SEV_ES))
>  		pr_info("SEV-ES %s (ASIDs %u - %u)\n",
> -			sev_es_supported ? min_sev_es_asid <= max_sev_es_asid ? "enabled" :
> -										"unusable" :
> -										"disabled",
> +			sev_str_feature_state(sev_es_supported, min_sev_es_asid <= max_sev_es_asid),
>  			min_sev_es_asid, max_sev_es_asid);
>  	if (boot_cpu_has(X86_FEATURE_SEV_SNP))
>  		pr_info("SEV-SNP %s (ASIDs %u - %u)\n",
> -			str_enabled_disabled(sev_snp_supported),
> +			sev_str_feature_state(sev_snp_supported, true),
>  			min_snp_asid, max_snp_asid);
>  
>  	sev_enabled = sev_supported;

[PATCH v3 5/7] KVM: SEV: Don't advertise support for unusable VM types

[Sean Christopherson]

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/aZyLIWtffvEnmtYh@google.com/
Suggested-by: Sean Christopherson <seanjc@google.com>
Signed-off-by: Tycho Andersen (AMD) <tycho@kernel.org>
[sean: land code in sev_hardware_setup()]
Signed-off-by: Sean Christopherson <seanjc@google.com>
---
 arch/x86/kvm/svm/sev.c | 19 +++++++++++--------
 1 file changed, 11 insertions(+), 8 deletions(-)

diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
index dfeb660b8f5d..0971cf652b0b 100644
--- a/arch/x86/kvm/svm/sev.c
+++ b/arch/x86/kvm/svm/sev.c
@@ -3062,6 +3062,7 @@ void __init sev_hardware_setup(void)
 	bool sev_snp_supported = false;
 	bool sev_es_supported = false;
 	bool sev_supported = false;
+	u32 vm_types = 0;
 
 	if (!sev_enabled || !npt_enabled || !nrips)
 		goto out;
@@ -3195,24 +3196,26 @@ void __init sev_hardware_setup(void)
 		}
 	}
 
-	if (sev_supported)
-		kvm_caps.supported_vm_types |= BIT(KVM_X86_SEV_VM);
-	if (sev_es_supported)
-		kvm_caps.supported_vm_types |= BIT(KVM_X86_SEV_ES_VM);
+	if (sev_supported && min_sev_asid <= max_sev_asid)
+		vm_types |= BIT(KVM_X86_SEV_VM);
+	if (sev_es_supported && min_sev_es_asid <= max_sev_es_asid)
+		vm_types |= BIT(KVM_X86_SEV_ES_VM);
 	if (sev_snp_supported)
-		kvm_caps.supported_vm_types |= BIT(KVM_X86_SNP_VM);
+		vm_types |= BIT(KVM_X86_SNP_VM);
+
+	kvm_caps.supported_vm_types |= vm_types;
 
 	if (boot_cpu_has(X86_FEATURE_SEV))
 		pr_info("SEV %s (ASIDs %u - %u)\n",
-			sev_str_feature_state(sev_supported, min_sev_asid <= max_sev_asid),
+			sev_str_feature_state(sev_supported, vm_types & BIT(KVM_X86_SEV_VM)),
 			min_sev_asid, max_sev_asid);
 	if (boot_cpu_has(X86_FEATURE_SEV_ES))
 		pr_info("SEV-ES %s (ASIDs %u - %u)\n",
-			sev_str_feature_state(sev_es_supported, min_sev_es_asid <= max_sev_es_asid),
+			sev_str_feature_state(sev_es_supported, vm_types & BIT(KVM_X86_SEV_ES_VM)),
 			min_sev_es_asid, max_sev_es_asid);
 	if (boot_cpu_has(X86_FEATURE_SEV_SNP))
 		pr_info("SEV-SNP %s (ASIDs %u - %u)\n",
-			sev_str_feature_state(sev_snp_supported, true),
+			sev_str_feature_state(sev_snp_supported, vm_types & BIT(KVM_X86_SNP_VM)),
 			min_snp_asid, max_snp_asid);
 
 	sev_enabled = sev_supported;
-- 
2.54.0.rc1.513.gad8abe7a5a-goog

Re: [PATCH v3 5/7] KVM: SEV: Don't advertise support for unusable VM types

[Tom Lendacky]

On 4/16/26 18:23, Sean Christopherson wrote:
> 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/aZyLIWtffvEnmtYh@google.com/
> Suggested-by: Sean Christopherson <seanjc@google.com>
> Signed-off-by: Tycho Andersen (AMD) <tycho@kernel.org>
> [sean: land code in sev_hardware_setup()]
> Signed-off-by: Sean Christopherson <seanjc@google.com>

Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>

> ---
>  arch/x86/kvm/svm/sev.c | 19 +++++++++++--------
>  1 file changed, 11 insertions(+), 8 deletions(-)
> 
> diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
> index dfeb660b8f5d..0971cf652b0b 100644
> --- a/arch/x86/kvm/svm/sev.c
> +++ b/arch/x86/kvm/svm/sev.c
> @@ -3062,6 +3062,7 @@ void __init sev_hardware_setup(void)
>  	bool sev_snp_supported = false;
>  	bool sev_es_supported = false;
>  	bool sev_supported = false;
> +	u32 vm_types = 0;
>  
>  	if (!sev_enabled || !npt_enabled || !nrips)
>  		goto out;
> @@ -3195,24 +3196,26 @@ void __init sev_hardware_setup(void)
>  		}
>  	}
>  
> -	if (sev_supported)
> -		kvm_caps.supported_vm_types |= BIT(KVM_X86_SEV_VM);
> -	if (sev_es_supported)
> -		kvm_caps.supported_vm_types |= BIT(KVM_X86_SEV_ES_VM);
> +	if (sev_supported && min_sev_asid <= max_sev_asid)
> +		vm_types |= BIT(KVM_X86_SEV_VM);
> +	if (sev_es_supported && min_sev_es_asid <= max_sev_es_asid)
> +		vm_types |= BIT(KVM_X86_SEV_ES_VM);
>  	if (sev_snp_supported)
> -		kvm_caps.supported_vm_types |= BIT(KVM_X86_SNP_VM);
> +		vm_types |= BIT(KVM_X86_SNP_VM);
> +
> +	kvm_caps.supported_vm_types |= vm_types;
>  
>  	if (boot_cpu_has(X86_FEATURE_SEV))
>  		pr_info("SEV %s (ASIDs %u - %u)\n",
> -			sev_str_feature_state(sev_supported, min_sev_asid <= max_sev_asid),
> +			sev_str_feature_state(sev_supported, vm_types & BIT(KVM_X86_SEV_VM)),
>  			min_sev_asid, max_sev_asid);
>  	if (boot_cpu_has(X86_FEATURE_SEV_ES))
>  		pr_info("SEV-ES %s (ASIDs %u - %u)\n",
> -			sev_str_feature_state(sev_es_supported, min_sev_es_asid <= max_sev_es_asid),
> +			sev_str_feature_state(sev_es_supported, vm_types & BIT(KVM_X86_SEV_ES_VM)),
>  			min_sev_es_asid, max_sev_es_asid);
>  	if (boot_cpu_has(X86_FEATURE_SEV_SNP))
>  		pr_info("SEV-SNP %s (ASIDs %u - %u)\n",
> -			sev_str_feature_state(sev_snp_supported, true),
> +			sev_str_feature_state(sev_snp_supported, vm_types & BIT(KVM_X86_SNP_VM)),
>  			min_snp_asid, max_snp_asid);
>  
>  	sev_enabled = sev_supported;

[PATCH v3 6/7] KVM: SEV: Don't advertise VM types that are disabled by firmware

[Sean Christopherson]

From: Tycho Andersen <tycho@kernel.org>

As called out in a footnote for a recent SNP vulnerability[1], it is
possible for a specific flavor of SEV+ to be disabled by the firmware even
when the flavor is fully supported by the CPU and platform:

  Applying mitigation CVE-2025-48514 will result in disabling SEV-ES when
  SEV-SNP is enabled.

Restrict KVM's set of supported VM types based on the VM types that are
fully supported by firmware to avoid over-reporting what KVM can actually
support.  Like KVM's handling of ASID space exhaustion, don't modify KVM's
CPUID capabilities, as the CPU/platform still supports the underlying
technology and clearing e.g. SEV_ES while advertising SEV_SNP would confuse
KVM and userspace.

Link: https://www.amd.com/en/resources/product-security/bulletin/amd-sb-3023.html [1]
Link: https://lore.kernel.org/all/aZyLIWtffvEnmtYh@google.com
Suggested-by: Sean Christopherson <seanjc@google.com>
Signed-off-by: Tycho Andersen (AMD) <tycho@kernel.org>
[sean: rewrite changelog to provide details on why/how this can happen]
Signed-off-by: Sean Christopherson <seanjc@google.com>
---
 arch/x86/kvm/svm/sev.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
index 0971cf652b0b..ab386aa0c284 100644
--- a/arch/x86/kvm/svm/sev.c
+++ b/arch/x86/kvm/svm/sev.c
@@ -3202,6 +3202,7 @@ void __init sev_hardware_setup(void)
 		vm_types |= BIT(KVM_X86_SEV_ES_VM);
 	if (sev_snp_supported)
 		vm_types |= BIT(KVM_X86_SNP_VM);
+	vm_types &= sev_firmware_supported_vm_types();
 
 	kvm_caps.supported_vm_types |= vm_types;
 
-- 
2.54.0.rc1.513.gad8abe7a5a-goog

Re: [PATCH v3 6/7] KVM: SEV: Don't advertise VM types that are disabled by firmware

[Tom Lendacky]

On 4/16/26 18:23, Sean Christopherson wrote:
> From: Tycho Andersen <tycho@kernel.org>
> 
> As called out in a footnote for a recent SNP vulnerability[1], it is
> possible for a specific flavor of SEV+ to be disabled by the firmware even
> when the flavor is fully supported by the CPU and platform:
> 
>   Applying mitigation CVE-2025-48514 will result in disabling SEV-ES when
>   SEV-SNP is enabled.
> 
> Restrict KVM's set of supported VM types based on the VM types that are
> fully supported by firmware to avoid over-reporting what KVM can actually
> support.  Like KVM's handling of ASID space exhaustion, don't modify KVM's
> CPUID capabilities, as the CPU/platform still supports the underlying
> technology and clearing e.g. SEV_ES while advertising SEV_SNP would confuse
> KVM and userspace.
> 
> Link: https://www.amd.com/en/resources/product-security/bulletin/amd-sb-3023.html [1]
> Link: https://lore.kernel.org/all/aZyLIWtffvEnmtYh@google.com
> Suggested-by: Sean Christopherson <seanjc@google.com>
> Signed-off-by: Tycho Andersen (AMD) <tycho@kernel.org>
> [sean: rewrite changelog to provide details on why/how this can happen]
> Signed-off-by: Sean Christopherson <seanjc@google.com>

That added line gets a little lost to my eyes by not having a blank line
in between, but that's just me :)

Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>

> ---
>  arch/x86/kvm/svm/sev.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
> index 0971cf652b0b..ab386aa0c284 100644
> --- a/arch/x86/kvm/svm/sev.c
> +++ b/arch/x86/kvm/svm/sev.c
> @@ -3202,6 +3202,7 @@ void __init sev_hardware_setup(void)
>  		vm_types |= BIT(KVM_X86_SEV_ES_VM);
>  	if (sev_snp_supported)
>  		vm_types |= BIT(KVM_X86_SNP_VM);
> +	vm_types &= sev_firmware_supported_vm_types();
>  
>  	kvm_caps.supported_vm_types |= vm_types;
>  

[PATCH v3 7/7] KVM: selftests: Teach sev_*_test about revoking VM types

[Sean Christopherson]

From: Tycho Andersen <tycho@kernel.org>

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.

Suggested-by: Sean Christopherson <seanjc@google.com>
Signed-off-by: Tycho Andersen (AMD) <tycho@kernel.org>
Signed-off-by: Sean Christopherson <seanjc@google.com>
---
 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(-)

diff --git a/tools/testing/selftests/kvm/x86/sev_init2_tests.c b/tools/testing/selftests/kvm/x86/sev_init2_tests.c
index b238615196ad..97bd036b4f1c 100644
--- a/tools/testing/selftests/kvm/x86/sev_init2_tests.c
+++ b/tools/testing/selftests/kvm/x86/sev_init2_tests.c
@@ -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();
 
diff --git a/tools/testing/selftests/kvm/x86/sev_migrate_tests.c b/tools/testing/selftests/kvm/x86/sev_migrate_tests.c
index 6b0928e69051..42bc023d5193 100644
--- a/tools/testing/selftests/kvm/x86/sev_migrate_tests.c
+++ b/tools/testing/selftests/kvm/x86/sev_migrate_tests.c
@@ -374,7 +374,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);
diff --git a/tools/testing/selftests/kvm/x86/sev_smoke_test.c b/tools/testing/selftests/kvm/x86/sev_smoke_test.c
index 8bd37a476f15..f3c39335ff39 100644
--- a/tools/testing/selftests/kvm/x86/sev_smoke_test.c
+++ b/tools/testing/selftests/kvm/x86/sev_smoke_test.c
@@ -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;
-- 
2.54.0.rc1.513.gad8abe7a5a-goog

Re: [PATCH v3 0/7] KVM: SEV: Don't advertise unusable VM types

[Tycho Andersen]

On Thu, Apr 16, 2026 at 04:23:22PM -0700, Sean Christopherson wrote:
> My preference would be to take this through the KVM tree, with acks on the
> crypto patches.  I'd also be a-ok with a stable branch/tag of the crypto
> changes.
> 
> In the words of Tycho:
> 
> 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.

I re-ran my matrix of firmware tests:

Tested-by: Tycho Andersen (AMD) <tycho@kernel.org>

Thanks for cleaning this up.

Tycho