[PATCH 6.12.y 0/4] crypto: ccp, KVM: SVM - missing SEV/SNP platform-init dependency + 2 bugfixes

[PATCH 6.12.y 0/4] crypto: ccp, KVM: SVM - missing SEV/SNP platform-init dependency + 2 bugfixes

[Jack Wang]

From: Jack Wang <jinpu.wang@cloud.ionos.com>

Hello Greg, hello Sasha

Backport of 4 upstream commits to 6.12.y (applies on stable-rc
queue/6.12), Option 3 of stable-kernel-rules.rst (no Cc: stable tag
upstream).

Patches 1-2 are the missing dependencies of commit 3f8f0133a5fc
("crypto: ccp - Move SEV/SNP Platform initialization to KVM"), already
queued as of 6.12.97 (bb1c8464702540 on queue/6.12). That commit
dropped SEV/SNP platform init from the CCP driver's probe path,
expecting KVM to take over, but the counterpart commits that give KVM
that responsibility were never queued alongside it. Net effect:
6.12.97+ has no code path left that initializes SEV/SNP, so starting a
SEV-SNP guest crashes the host.

1) crypto: ccp - Add new SEV/SNP platform shutdown API
   Upstream f7b86e0e75bc234751cb7a82d888083a57ef28b2

2) KVM: SVM: Add support to initialize SEV/SNP functionality in KVM
   Upstream 6f1d5a3513c2370bbd6115dd430906bc2f4bdc53

Patches 3-4 are unrelated, independent bugfixes:

3) crypto: ccp - Fix checks for SNP_VLEK_LOAD input buffer length
   Upstream ed53a5050f42a3243a7ed8dfa49030e54034b952
   Context deviation: 6.12.y lacks the SEV_CMD_SNP_FEATURE_INFO case
   the upstream hunk anchors on (added later, not queued here), so
   the new case was placed after SEV_CMD_SNP_COMMIT instead. No
   functional difference; noted as [Jack: ...] in the commit.

4) crypto: ccp - Abort doing SEV INIT if SNP INIT fails
   Upstream 6131e119f5799bec55535530fa2fc44f5c7be1f1
   Fixes SEV INIT succeeding to be issued (and failing) even when SNP
   host support is enabled and SNP_INIT(_EX) hasn't succeeded.

Patches 1, 2 and 4 applied clean; only patch 3 needed the context
adjustment above. Please consider queue them for future release.

Thanks,
Jack Wang @ IONOS Cloud

Ashish Kalra (3):
  crypto: ccp - Add new SEV/SNP platform shutdown API
  KVM: SVM: Add support to initialize SEV/SNP functionality in KVM
  crypto: ccp - Abort doing SEV INIT if SNP INIT fails

Michael Roth (1):
  crypto: ccp - Fix checks for SNP_VLEK_LOAD input buffer length

 arch/x86/kvm/svm/sev.c       | 12 ++++++++++++
 drivers/crypto/ccp/sev-dev.c | 17 ++++++++++++-----
 include/linux/psp-sev.h      |  3 +++
 3 files changed, 27 insertions(+), 5 deletions(-)

-- 
2.43.0

[stable-6.12 1/4] crypto: ccp - Add new SEV/SNP platform shutdown API

[Jack Wang]

From: Ashish Kalra <ashish.kalra@amd.com>

commit f7b86e0e75bc234751cb7a82d888083a57ef28b2 upstream.

Add new API interface to do SEV/SNP platform shutdown when KVM module
is unloaded.

Reviewed-by: Dionna Glaze <dionnaglaze@google.com>
Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: Ashish Kalra <ashish.kalra@amd.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Jack Wang <jinpu.wang@cloud.ionos.com>
---
 drivers/crypto/ccp/sev-dev.c | 9 +++++++++
 include/linux/psp-sev.h      | 3 +++
 2 files changed, 12 insertions(+)

diff --git a/drivers/crypto/ccp/sev-dev.c b/drivers/crypto/ccp/sev-dev.c
index d668f9318c28..7c05cae7e577 100644
--- a/drivers/crypto/ccp/sev-dev.c
+++ b/drivers/crypto/ccp/sev-dev.c
@@ -2444,6 +2444,15 @@ static void sev_firmware_shutdown(struct sev_device *sev)
 	mutex_unlock(&sev_cmd_mutex);
 }
 
+void sev_platform_shutdown(void)
+{
+	if (!psp_master || !psp_master->sev_data)
+		return;
+
+	sev_firmware_shutdown(psp_master->sev_data);
+}
+EXPORT_SYMBOL_GPL(sev_platform_shutdown);
+
 void sev_dev_destroy(struct psp_device *psp)
 {
 	struct sev_device *sev = psp->sev_data;
diff --git a/include/linux/psp-sev.h b/include/linux/psp-sev.h
index 613a8209bed2..6a4435cfa977 100644
--- a/include/linux/psp-sev.h
+++ b/include/linux/psp-sev.h
@@ -947,6 +947,7 @@ int sev_do_cmd(int cmd, void *data, int *psp_ret);
 void *psp_copy_user_blob(u64 uaddr, u32 len);
 void *snp_alloc_firmware_page(gfp_t mask);
 void snp_free_firmware_page(void *addr);
+void sev_platform_shutdown(void);
 
 #else	/* !CONFIG_CRYPTO_DEV_SP_PSP */
 
@@ -981,6 +982,8 @@ static inline void *snp_alloc_firmware_page(gfp_t mask)
 
 static inline void snp_free_firmware_page(void *addr) { }
 
+static inline void sev_platform_shutdown(void) { }
+
 #endif	/* CONFIG_CRYPTO_DEV_SP_PSP */
 
 #endif	/* __PSP_SEV_H__ */
-- 
2.43.0

[stable-6.12 2/4] KVM: SVM: Add support to initialize SEV/SNP functionality in KVM

[Jack Wang]

From: Ashish Kalra <ashish.kalra@amd.com>

commit 6f1d5a3513c2370bbd6115dd430906bc2f4bdc53 upstream.

Move platform initialization of SEV/SNP from CCP driver probe time to
KVM module load time so that KVM can do SEV/SNP platform initialization
explicitly if it actually wants to use SEV/SNP functionality.

Add support for KVM to explicitly call into the CCP driver at load time
to initialize SEV/SNP. If required, this behavior can be altered with KVM
module parameters to not do SEV/SNP platform initialization at module load
time. Additionally, a corresponding SEV/SNP platform shutdown is invoked
during KVM module unload time.

Continue to support SEV deferred initialization as the user may have the
file containing SEV persistent data for SEV INIT_EX available only later
after module load/init.

Suggested-by: Sean Christopherson <seanjc@google.com>
Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: Ashish Kalra <ashish.kalra@amd.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Jack Wang <jinpu.wang@cloud.ionos.com>
---
 arch/x86/kvm/svm/sev.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
index 6cec696461da..bd0344bacaf1 100644
--- a/arch/x86/kvm/svm/sev.c
+++ b/arch/x86/kvm/svm/sev.c
@@ -2972,6 +2972,7 @@ void __init sev_set_cpu_caps(void)
 void __init sev_hardware_setup(void)
 {
 	unsigned int eax, ebx, ecx, edx, sev_asid_count, sev_es_asid_count;
+	struct sev_platform_init_args init_args = {0};
 	bool sev_snp_supported = false;
 	bool sev_es_supported = false;
 	bool sev_supported = false;
@@ -3088,6 +3089,15 @@ void __init sev_hardware_setup(void)
 	sev_supported_vmsa_features = 0;
 	if (sev_es_debug_swap_enabled)
 		sev_supported_vmsa_features |= SVM_SEV_FEAT_DEBUG_SWAP;
+
+	if (!sev_enabled)
+		return;
+
+	/*
+	 * Do both SNP and SEV initialization at KVM module load.
+	 */
+	init_args.probe = true;
+	sev_platform_init(&init_args);
 }
 
 void sev_hardware_unsetup(void)
@@ -3103,6 +3113,8 @@ void sev_hardware_unsetup(void)
 
 	misc_cg_set_capacity(MISC_CG_RES_SEV, 0);
 	misc_cg_set_capacity(MISC_CG_RES_SEV_ES, 0);
+
+	sev_platform_shutdown();
 }
 
 int sev_cpu_init(struct svm_cpu_data *sd)
-- 
2.43.0

[stable-6.12 3/4] crypto: ccp - Fix checks for SNP_VLEK_LOAD input buffer length

[Jack Wang]

From: Michael Roth <michael.roth@amd.com>

commit ed53a5050f42a3243a7ed8dfa49030e54034b952 upstream.

The SNP_VLEK_LOAD IOCTL currently fails due to sev_cmd_buffer_len()
returning the default expected buffer length of 0 instead of the correct
value, which would be sizeof(struct sev_user_data_snp_vlek_load). Add
specific handling for SNP_VLEK_LOAD so the correct expected size is
returned.

Reported-by: Diego GonzalezVillalobos <Diego.GonzalezVillalobos@amd.com>
Cc: Diego GonzalezVillalobos <Diego.GonzalezVillalobos@amd.com>
Fixes: 332d2c1d713e ("crypto: ccp: Add the SNP_VLEK_LOAD command")
Signed-off-by: Michael Roth <michael.roth@amd.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
[Jack: sev_cmd_buffer_len() in queue/6.12 does not yet have the
 SEV_CMD_SNP_FEATURE_INFO case the upstream context line matched
 against (it lands in a later, unrelated commit not queued here),
 so the new SEV_CMD_SNP_VLEK_LOAD case was placed directly after
 SEV_CMD_SNP_COMMIT instead. No functional difference from upstream.]
Signed-off-by: Jack Wang <jinpu.wang@cloud.ionos.com>
---
 drivers/crypto/ccp/sev-dev.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/crypto/ccp/sev-dev.c b/drivers/crypto/ccp/sev-dev.c
index 7c05cae7e577..6e08378eb5fa 100644
--- a/drivers/crypto/ccp/sev-dev.c
+++ b/drivers/crypto/ccp/sev-dev.c
@@ -226,6 +226,7 @@ static int sev_cmd_buffer_len(int cmd)
 	case SEV_CMD_SNP_GUEST_REQUEST:		return sizeof(struct sev_data_snp_guest_request);
 	case SEV_CMD_SNP_CONFIG:		return sizeof(struct sev_user_data_snp_config);
 	case SEV_CMD_SNP_COMMIT:		return sizeof(struct sev_data_snp_commit);
+	case SEV_CMD_SNP_VLEK_LOAD:		return sizeof(struct sev_user_data_snp_vlek_load);
 	default:				return 0;
 	}
 
-- 
2.43.0

[stable-6.12 4/4] crypto: ccp - Abort doing SEV INIT if SNP INIT fails

[Jack Wang]

From: Ashish Kalra <ashish.kalra@amd.com>

commit 6131e119f5799bec55535530fa2fc44f5c7be1f1 upstream.

If SNP host support (SYSCFG.SNPEn) is set, then the RMP table must
be initialized before calling SEV INIT.

In other words, if SNP_INIT(_EX) is not issued or fails then
SEV INIT will fail if SNP host support (SYSCFG.SNPEn) is enabled.

Signed-off-by: Ashish Kalra <ashish.kalra@amd.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Jack Wang <jinpu.wang@cloud.ionos.com>
---
 drivers/crypto/ccp/sev-dev.c | 7 ++-----
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/crypto/ccp/sev-dev.c b/drivers/crypto/ccp/sev-dev.c
index 6e08378eb5fa..d6a0773d6da8 100644
--- a/drivers/crypto/ccp/sev-dev.c
+++ b/drivers/crypto/ccp/sev-dev.c
@@ -1118,7 +1118,7 @@ static int __sev_snp_init_locked(int *error)
 	if (!sev_version_greater_or_equal(SNP_MIN_API_MAJOR, SNP_MIN_API_MINOR)) {
 		dev_dbg(sev->dev, "SEV-SNP support requires firmware version >= %d:%d\n",
 			SNP_MIN_API_MAJOR, SNP_MIN_API_MINOR);
-		return 0;
+		return -EOPNOTSUPP;
 	}
 
 	/* SNP_INIT requires MSR_VM_HSAVE_PA to be cleared on all CPUs. */
@@ -1357,12 +1357,9 @@ static int _sev_platform_init_locked(struct sev_platform_init_args *args)
 
 	rc = __sev_snp_init_locked(&args->error);
 	if (rc && rc != -ENODEV) {
-		/*
-		 * Don't abort the probe if SNP INIT failed,
-		 * continue to initialize the legacy SEV firmware.
-		 */
 		dev_err(sev->dev, "SEV-SNP: failed to INIT rc %d, error %#x\n",
 			rc, args->error);
+		return rc;
 	}
 
 	/* Defer legacy SEV/SEV-ES support if allowed by caller/module. */
-- 
2.43.0

Re: [stable-6.12 2/4] KVM: SVM: Add support to initialize SEV/SNP functionality in KVM

[Sean Christopherson]

On Fri, Aug 14, 2026, Jack Wang wrote:
> From: Ashish Kalra <ashish.kalra@amd.com>
> 
> commit 6f1d5a3513c2370bbd6115dd430906bc2f4bdc53 upstream.
> 
> Move platform initialization of SEV/SNP from CCP driver probe time to
> KVM module load time so that KVM can do SEV/SNP platform initialization
> explicitly if it actually wants to use SEV/SNP functionality.
> 
> Add support for KVM to explicitly call into the CCP driver at load time
> to initialize SEV/SNP. If required, this behavior can be altered with KVM
> module parameters to not do SEV/SNP platform initialization at module load
> time. Additionally, a corresponding SEV/SNP platform shutdown is invoked
> during KVM module unload time.
> 
> Continue to support SEV deferred initialization as the user may have the
> file containing SEV persistent data for SEV INIT_EX available only later
> after module load/init.
> 
> Suggested-by: Sean Christopherson <seanjc@google.com>
> Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
> Signed-off-by: Ashish Kalra <ashish.kalra@amd.com>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
> Signed-off-by: Jack Wang <jinpu.wang@cloud.ionos.com>
> ---

Acked-by: Sean Christopherson <seanjc@google.com>

Re: [PATCH 6.12.y 0/4] crypto: ccp, KVM: SVM - missing SEV/SNP platform-init dependency + 2 bugfixes

[Sasha Levin]

> Patches 1-2 are the missing dependencies of commit 3f8f0133a5fc
> ("crypto: ccp - Move SEV/SNP Platform initialization to KVM"), already
> queued as of 6.12.97 (bb1c8464702540 on queue/6.12). That commit
> dropped SEV/SNP platform init from the CCP driver's probe path,
> expecting KVM to take over, but the counterpart commits that give KVM
> that responsibility were never queued alongside it.

Queued the series for 6.12, thanks.

-- 
Thanks,
Sasha

Re: [PATCH 6.12.y 0/4] crypto: ccp, KVM: SVM - missing SEV/SNP platform-init dependency + 2 bugfixes

[Jinpu Wang]

On Sat, Aug 15, 2026 at 4:33 AM Sasha Levin <sashal@kernel.org> wrote:
>
> > Patches 1-2 are the missing dependencies of commit 3f8f0133a5fc
> > ("crypto: ccp - Move SEV/SNP Platform initialization to KVM"), already
> > queued as of 6.12.97 (bb1c8464702540 on queue/6.12). That commit
> > dropped SEV/SNP platform init from the CCP driver's probe path,
> > expecting KVM to take over, but the counterpart commits that give KVM
> > that responsibility were never queued alongside it.
>
> Queued the series for 6.12, thanks.
>
> --
> Thanks,
> Sasha
Hi Sasha,

Thanks for queueing the series.

It might be worth adding a rule for the stable-kernel scripts to
ensure they don't pick a single patch from the middle of an upstream
patchset. This could help prevent future regressions like this one,
where a commit dropped functionality in anticipation of a counterpart
commit that was left behind.

Thanks,
J

Re: [PATCH 6.12.y 0/4] crypto: ccp, KVM: SVM - missing SEV/SNP platform-init dependency + 2 bugfixes

[Greg KH]

On Mon, Aug 17, 2026 at 06:51:27AM +0200, Jinpu Wang wrote:
> On Sat, Aug 15, 2026 at 4:33 AM Sasha Levin <sashal@kernel.org> wrote:
> >
> > > Patches 1-2 are the missing dependencies of commit 3f8f0133a5fc
> > > ("crypto: ccp - Move SEV/SNP Platform initialization to KVM"), already
> > > queued as of 6.12.97 (bb1c8464702540 on queue/6.12). That commit
> > > dropped SEV/SNP platform init from the CCP driver's probe path,
> > > expecting KVM to take over, but the counterpart commits that give KVM
> > > that responsibility were never queued alongside it.
> >
> > Queued the series for 6.12, thanks.
> >
> > --
> > Thanks,
> > Sasha
> Hi Sasha,
> 
> Thanks for queueing the series.
> 
> It might be worth adding a rule for the stable-kernel scripts to
> ensure they don't pick a single patch from the middle of an upstream
> patchset. This could help prevent future regressions like this one,
> where a commit dropped functionality in anticipation of a counterpart
> commit that was left behind.

How do we "know" a patch is in the middle of a patchset just by looking
at the git tree?

thanks,

greg k-h

Re: [PATCH 6.12.y 0/4] crypto: ccp, KVM: SVM - missing SEV/SNP platform-init dependency + 2 bugfixes

[Jinpu Wang]

On Mon, Aug 17, 2026 at 7:01 AM Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Mon, Aug 17, 2026 at 06:51:27AM +0200, Jinpu Wang wrote:
> > On Sat, Aug 15, 2026 at 4:33 AM Sasha Levin <sashal@kernel.org> wrote:
> > >
> > > > Patches 1-2 are the missing dependencies of commit 3f8f0133a5fc
> > > > ("crypto: ccp - Move SEV/SNP Platform initialization to KVM"), already
> > > > queued as of 6.12.97 (bb1c8464702540 on queue/6.12). That commit
> > > > dropped SEV/SNP platform init from the CCP driver's probe path,
> > > > expecting KVM to take over, but the counterpart commits that give KVM
> > > > that responsibility were never queued alongside it.
> > >
> > > Queued the series for 6.12, thanks.
> > >
> > > --
> > > Thanks,
> > > Sasha
> > Hi Sasha,
> >
> > Thanks for queueing the series.
> >
> > It might be worth adding a rule for the stable-kernel scripts to
> > ensure they don't pick a single patch from the middle of an upstream
> > patchset. This could help prevent future regressions like this one,
> > where a commit dropped functionality in anticipation of a counterpart
> > commit that was left behind.
>
> How do we "know" a patch is in the middle of a patchset just by looking
> at the git tree?
>
Hi Greg,

I agree it is difficult to know purely from the git tree. For my own
automation, I have added the following rule to my Claude.md:

Before backporting any commit, check whether it's part of a
multi-patch series and, if so, pull in the whole series rather than a
subset:

  - Look for series markers on the commit and its neighbors:
Stable-dep-of: trailers, matching Suggested-by/Reviewed-by sets, same
author + adjacent commit dates, and a shared subject-line topic.
  - Walk both directions: check commits immediately before/after it in
upstream history from the same author/topic, not just the one commit
named in the request.
  - If the commit being backported removes/changes behavior that
another sibling commit is meant to replace (e.g. moving a
responsibility from driver A to subsystem B), verify the replacement
sibling is already present in the target tree or is being added
alongside it — don't land one half of a two-sided change.

The reason for this is that we queued 3f8f0133a5fc ("crypto: ccp -
Move SEV/SNP Platform initialization to KVM") without its counterpart
KVM-side init/shutdown commits, leaving 6.12.97+ with no code path
that initializes SEV/SNP, which causes a host crash on SEV-SNP VM
start. A series-completeness check like this would have caught it.

Thanks,
J
> thanks,
>
> greg k-h

Re: [PATCH 6.12.y 0/4] crypto: ccp, KVM: SVM - missing SEV/SNP platform-init dependency + 2 bugfixes

[Greg KH]

On Mon, Aug 17, 2026 at 07:22:36AM +0200, Jinpu Wang wrote:
> On Mon, Aug 17, 2026 at 7:01 AM Greg KH <gregkh@linuxfoundation.org> wrote:
> >
> > On Mon, Aug 17, 2026 at 06:51:27AM +0200, Jinpu Wang wrote:
> > > On Sat, Aug 15, 2026 at 4:33 AM Sasha Levin <sashal@kernel.org> wrote:
> > > >
> > > > > Patches 1-2 are the missing dependencies of commit 3f8f0133a5fc
> > > > > ("crypto: ccp - Move SEV/SNP Platform initialization to KVM"), already
> > > > > queued as of 6.12.97 (bb1c8464702540 on queue/6.12). That commit
> > > > > dropped SEV/SNP platform init from the CCP driver's probe path,
> > > > > expecting KVM to take over, but the counterpart commits that give KVM
> > > > > that responsibility were never queued alongside it.
> > > >
> > > > Queued the series for 6.12, thanks.
> > > >
> > > > --
> > > > Thanks,
> > > > Sasha
> > > Hi Sasha,
> > >
> > > Thanks for queueing the series.
> > >
> > > It might be worth adding a rule for the stable-kernel scripts to
> > > ensure they don't pick a single patch from the middle of an upstream
> > > patchset. This could help prevent future regressions like this one,
> > > where a commit dropped functionality in anticipation of a counterpart
> > > commit that was left behind.
> >
> > How do we "know" a patch is in the middle of a patchset just by looking
> > at the git tree?
> >
> Hi Greg,
> 
> I agree it is difficult to know purely from the git tree. For my own
> automation, I have added the following rule to my Claude.md:
> 
> Before backporting any commit, check whether it's part of a
> multi-patch series and, if so, pull in the whole series rather than a
> subset:
> 
>   - Look for series markers on the commit and its neighbors:
> Stable-dep-of: trailers, matching Suggested-by/Reviewed-by sets, same
> author + adjacent commit dates, and a shared subject-line topic.

Stable-dep-of comes from us, not in Linus's tree.

>   - Walk both directions: check commits immediately before/after it in
> upstream history from the same author/topic, not just the one commit
> named in the request.
>   - If the commit being backported removes/changes behavior that
> another sibling commit is meant to replace (e.g. moving a
> responsibility from driver A to subsystem B), verify the replacement
> sibling is already present in the target tree or is being added
> alongside it — don't land one half of a two-sided change.

Nice, but given you are using a non-determinisitic tool, odds are it
will not always work :)

We need reliability for stuff like this, not LLM messes, sorry.

> The reason for this is that we queued 3f8f0133a5fc ("crypto: ccp -
> Move SEV/SNP Platform initialization to KVM") without its counterpart
> KVM-side init/shutdown commits, leaving 6.12.97+ with no code path
> that initializes SEV/SNP, which causes a host crash on SEV-SNP VM
> start. A series-completeness check like this would have caught it.

But does it actually catch it with your tool?

Does your tool catch anything else we have missed?  We often see stable
tags in the beginning of patch series, and sometimes at the end, or in
the middle (ok just about anywhere), because that's ok.  Just look on
lkml for loads of examples of where this is just fine and if we were to
take the additional changes, that is not what the original author
wanted.

thanks,

greg k-h