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.
Thank you all very much!
Very Respectfully,
Andrew Wilson
On Wed, Sep 2, 2026 at 1:06 PM Sean Christopherson <[email protected]> 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/[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]
>
> > ### 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
