Re: [PATCH 6.12 111/181] KVM: SVM: Add support to initialize SEV/SNP functionality in KVM

Hi Harshit,

On Wed, Aug 19, 2026 at 9:12 AM Harshit Mogalapalli
<[email protected]> wrote:
>
> Hi Jack, Greg, Sasha,
>
>
> On 17/08/26 7:03 pm, Greg Kroah-Hartman wrote:
> > 6.12-stable review patch.  If anyone has any objections, please let me know.
> >
> > ------------------
> >
> > From: Ashish Kalra <[email protected]>
> >
> > 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 <[email protected]>
> > Reviewed-by: Tom Lendacky <[email protected]>
> > Signed-off-by: Ashish Kalra <[email protected]>
> > Signed-off-by: Herbert Xu <[email protected]>
> > Signed-off-by: Jack Wang <[email protected]>
> > Signed-off-by: Sasha Levin <[email protected]>
> > ---
> >   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 6cec696461da2..bd0344bacaf1e 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);
> >   }
> >
>
> I ran an AI-assisted backport review and checked the finding against
> 6.12.y. The backport appears to be missing the ordering used upstream
> when kvm_amd is built-in.
>
> Upstream ensures that the PSP driver is ready before KVM continues:
>
>         if (IS_BUILTIN(CONFIG_KVM_AMD) && sev_module_init())
>                 goto out;
>
> It also initializes the SNP RMP table from AMD IOMMU initialization:
>
>         if (snp_rmptable_init())
>                 goto disable_snp;
>
> 6.12.y has no sev_module_init() call and still initializes the RMP table
> through a later initcall:
>
>         device_initcall(snp_rmptable_init);
>
> The backport can therefore reach:
>
>         init_args.probe = true;
>         sev_platform_init(&init_args);
>
> before the PSP device exists. The call returns -ENODEV and its result is
> ignored. KVM can then enable SVM before SNP/RMP setup has completed.
> Since bb1c84647025 removed probe-time platform initialization, this can
> leave encrypted guests unable to start.
>
That looks like the case, we only use kvm as module, didn't hit the issue.
> The relevant upstream commits are:
>
> 435b344a7042 ("crypto: ccp: Add external API interface for PSP module
> initialization")
> 44e70718df4f ("KVM: SVM: Ensure PSP module is initialized if KVM module
> is built-in")
> 409f45387c93 ("x86/sev: Fix broken SNP support with KVM module built-in")
>
>
> https://lore.kernel.org/stable/[email protected]/
>
>
> Could the KVM maintainers confirm whether 6.12.y needs this full series
> ? Probably could be done after this cycle, but still noting it here.
+1
>
> thanks,
> Harshit
Thanks!
> >   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)
>