Re: [REGRESSION] [6.12.y] crypto: ccp - Move SEV/SNP Platform initialization to KVM breaks SEV-ES VM launch

[Andrew Wilson]

Hi Sean, Salvatore,

Tested-by: Andrew Wilson <your.email@xxxxxxxxxxx>

(With strong assistance from Gemini guiding me through builds, module
DKMS rebuilds, and interpreting logs!)

I can confirm that commit 6b748c39d18e completely resolves the issue,
and SEV, SEV-ES, AND SEV-SNP are fully functional on official Debian
packages (tested on EPYC Rome and EPYC Milan servers).

Here are the test results from bare-metal hardware:

1. Upstream v6.12.104 (Source build) on AMD EPYC (Rome):
   * Tested SEV-ES: Functional, VMs launch cleanly.

2. Debian 6.12.107-1 (linux-image-6.12.107+deb13-amd64) on AMD EPYC (Rome):
   * Tested SEV & SEV-ES: Functional.
   [    3.676036] kvm_amd: SEV enabled (ASIDs 16 - 253)
   [    3.690542] kvm_amd: SEV-ES enabled (ASIDs 1 - 15)
   [    3.735896] ccp 0000:26:00.1: SEV API:0.24 build:22

3. Debian 6.12.107-1 (linux-image-6.12.107+deb13-amd64) on AMD EPYC (Milan):
   * Tested SEV-SNP: Fully functional!
   * Host log:
     [    4.678767] kvm_amd: SEV enabled (ASIDs 256 - 509)
     [    4.684694] kvm_amd: SEV-ES enabled (ASIDs 1 - 255)
     [    4.690563] kvm_amd: SEV-SNP enabled (ASIDs 1 - 255)
     [    6.212275] ccp 0000:47:00.1: SEV-SNP API:1.58 build:2
   * Guest dmesg:
     [    0.908804] Memory Encryption Features active: AMD SEV SEV-ES SEV-SNP
     [    0.908820] SEV: Status: SEV SEV-ES SEV-SNP
     [    2.109524] SEV: SNP running at VMPL0.
     [    3.439649] sev-guest sev-guest: Initialized SEV guest driver
(using VMPCK0 communication key)

Because Debian builds KVM as a module (CONFIG_KVM_AMD=m), we avoid the
built-in CONFIG_KVM_AMD=y SNP race on 6.12.y, so both SEV-ES and
SEV-SNP are completely working out-of-the-box on 6.12.107-1.

Salvatore: Debian bug #1145026 can be marked fully resolved by
linux-image-6.12.107-1.

Thank you all very much!

Very Respectfully,

Andrew Wilson

On Wed, Sep 2, 2026 at 1:06 PM Sean Christopherson <seanjc@xxxxxxxxxx> wrote:
>
> On Wed, Sep 02, 2026, Andrew Wilson wrote:
> > #regzbot introduced: 3f8f0133a5fc9b32d0c308530320c3f2430ba5ab
> >
> > Hi all,
> >
> > I am writing to report a regression affecting AMD SEV-ES VM launches
> > on the 6.12 stable branch (first noticed in 6.12.97+ / 6.12.101).
> >
> > I completed a git bisect between working and failing kernels, which pointed to:
> >
> > Commit: bb1c84647025 ("crypto: ccp - Move SEV/SNP Platform
> > initialization to KVM")
> > Upstream commit: 3f8f0133a5fc9b32d0c308530320c3f2430ba5ab
> >
> > ### Bisect & Verification Details:
> > * Last Known Working: 8a599f4f74d4
> > * First Broken Commit: bb1c84647025
> > * Tested on 6.12.101: Cleanly reverting bb1c84647025 immediately
> > resolves the issue and allows SEV-ES guests to boot normally.
>
> Can you try v6.12.104 or later?  I'm pretty sure this is fixed by commit
> 6b748c39d18e ("KVM: SVM: Add support to initialize SEV/SNP functionality in KVM"),
> i.e. is the same thing as:
> https://lore.kernel.org/all/20260814100652.225499-1-jinpu.wang@xxxxxxxxx
>
> Note, SNP is still buggered on 6.12.y if CONFIG_KVM_AMD=y, I'll try and send a
> backport for that soonish.
> https://lore.kernel.org/all/521b22fa-ef09-4449-909f-0120edfc4b24@xxxxxxxxxx
>
> > ### Failure Description:
> > With commit bb1c84647025 applied, `sev_platform_init(&args)` is
> > removed from `sev_pci_init()`, assuming KVM handles on-demand
> > initialization.
> >
> > On bare metal, the PSP firmware appears to remain uninitialized (does
> > not reach SEV_STATE_INIT at probe time). When QEMU initializes KVM and
> > queries host SEV-ES capabilities, the ioctl fails with -EPERM:
> >
> >   qemu-system-x86_64: -accel kvm: sev_common_kvm_init: guest policy
> > requires SEV-ES, but host SEV-ES support unavailable
> >   qemu-system-x86_64: -accel kvm: failed to initialize kvm: Operation
> > not permitted
> >
> > ### Hardware & Environment:
> > * Tested on: AMD EPYC (Rome / Milan) Supermicro platforms
> > * Kernel: Linux 6.12.101
> > * Hypervisor: QEMU / KVM
> >
> > I have access to Naples, Rome, and Milan test hardware and am happy to
> > test any patches, provide dmesg traces, or assist with debugging.  I
> > am not a tech-expert of any kind, but I have time to do some testing
> > if it helps.  THANK YOU for the great work.
> >
> > Original Debian bug reference:
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1145026