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

Reply via email to