crypto: ccp - Move SEV/SNP Platform initialization to KVM breaks SEV-ES VM launch

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

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

Quoted 13 lines · Andrew Wilson

#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

Quoted 5 lines

### 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/[email protected]

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/[email protected]

Quoted 26 lines

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

Hi Sean, Salvatore,

Tested-by Andrew Wilson <[email protected]>

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