Hi I just wanted to check in to see if my prior information was useful in identifying/confirming a bug? Is there anything else I can provide to assist?
Very Respectfully, Andrew Wilson ---------- Forwarded message --------- From: Andrew Wilson <[email protected]> Date: Sat, Aug 22, 2026 at 9:55 AM Subject: Re: Bug#1145026: Acknowledgement (linux-image-6.12.101+deb13-amd64: [REGRESSION] 6.12.101 breaks AMD SEV, SEV-ES, and SEV-SNP platform initialization) To: <[email protected]> Hi Debian Kernel Team, With the help of Gemini to help me interpret my results, I have completed a bisect on the upstream 6.12.y branch to pinpoint the exact commit causing this SEV-ES launch failure regression. My journey wasn't as clean and surgical as I would have liked (so it took longer), but I THINK I got there. The failure was introduced by: Commit: bb1c84647025 ("crypto: ccp - Move SEV/SNP Platform initialization to KVM") Upstream commit: 3f8f0133a5fc9b32d0c308530320c3f2430ba5ab --- ### Verification & Bisect Details: * LAST WORKING COMMIT: 8a599f4f74d4 * FIRST BROKEN COMMIT: bb1c84647025 (which landed in 6.12.97+) * Verified on 6.12.101: Cleanly reverting commit bb1c84647025 on top of 6.12.101 immediately fixes the issue and allows SEV-ES VMs to launch and run without errors. --- ### Failure Mechanism: Commit bb1c84647025 removed `sev_platform_init(&args)` from `sev_pci_init()` in `drivers/crypto/ccp/sev-dev.c` under the assumption that KVM would handle initialization on-demand. In practice on bare metal, the PSP firmware is left uninitialized (never transitions to SEV_STATE_INIT at probe time). When QEMU initializes the KVM accelerator and probes host SEV-ES capabilities, the ioctl fails with -EPERM, producing the error: 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 Reverting bb1c84647025 restores the probe-time initialization and resolves the regression. Please let me know if you need any additional hardware traces or logs. I have the time and resources to run tests if I can help - I have Milan, Rome and even Naples (nothing newer) servers and I can try to do some trials if it's helpful. THANK YOU for your wonderful work. I have never rebooted a supermicro server as much in my life as I have on this. LOL. I HOPE this is useful. Very Respectfully, Andrew Wilson On Fri, Aug 21, 2026 at 10:31 AM Debian Bug Tracking System < [email protected]> wrote: > Thank you for filing a new Bug report with Debian. > > You can follow progress on this Bug here: 1145026: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1145026. > > This is an automatically generated reply to let you know your message > has been received. > > Your message is being forwarded to the package maintainers and other > interested parties for their attention; they will reply in due course. > > As you requested using X-Debbugs-CC, your message was also forwarded to > [email protected] > (after having been given a Bug report number, if it did not have one). > > Your message has been sent to the package maintainer(s): > [email protected] > > If you wish to submit further information on this problem, please > send it to [email protected]. > > Please do not send mail to [email protected] unless you wish > to report a problem with the Bug-tracking system. > > -- > 1145026: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1145026 > Debian Bug Tracking System > Contact [email protected] with problems >
