Hi Dann, Thanks for the suggestion. So on my system with the latest 2025.02-8, i've tried both OVMF_CODE_4M.secboot.fd and OVMF_CODE_4M.secboot.strictnx.fd images. Between each attempt, i've deleted the virtual machine's nvram vars file to have those regenerated from the template.
In either cases, i unfortunately still observed the same exact behaviour (the VM using SEV does not boot with no message printed on the console and kvm process stuck at 100% CPU). Then, after putting back OVMF_CODE_4M.secboot.fd from 2024.02-2, it would start normally again. So it does not appear to be related with EFI_MEMORY_ATTRIBUTE (strictnx). Thanks for the help, Best regards, --- Stephane POIGNANT +33 682 960 589 On Saturday, July 19th, 2025 at 2:47 AM, dann frazier <da...@dannf.org> wrote: > On Sun, May 25, 2025 at 04:43:24PM +0000, Stephane Poignant wrote: > > > Subject: ovmf: Potential regression: ovmf package update from Debian > > bookworm to trixie breaks AMD-SEV > > Package: ovmf > > X-Debbugs-Cc: stephane.poign...@protonmail.com > > Version: 2025.02-6 > > Severity: normal > > > > After upgrading from bookworm to trixie (ovmf package upgraded from > > 2022.11-6+deb12u2 to 2025.02-6), my SEV encrypted VMs became unable to boot. > > > Hi Stephane, > > I don't have access to a system that supports SEV. But it's possible that > this is a symptom of the EFI_MEMORY_ATTRIBUTE protocol that was enabled in > 2025.02-6, but later disabled in 2025.02-8. Would you mind testing it and > reporting back? > > -dann