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 <
[email protected]> 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: [email protected]
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
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)