I guess we have to provide 4mb variants for the secure boot ones. I am experimenting with some of them to see which ones work. If you know how to do it quickly, it'd would save me some hassle and I can test on my machine.

I've got this so far - https://paste.xinu.at/13r/

I've got all the json files and a working PKGBUILD in the zip for testing.

If 4MB FD is the future, then there's no need for json files for non-4MB firmware.

Sure, but I can't find a concrete confirmation that that's the case.

edk2-ovmf-202208-2 is in testing - please have a look and test

edk2-ovmf-202208-2 causes my x86_64 libvirt VMs to fail during boot with the following error message:

!!!! X64 Exception Type - 06(#UD - Invalid Opcode) CPU Apic ID - 00000000 !!!!
RIP - 0000000000030000, CS - 0000000000000038, RFLAGS - 0000000000010246
RAX - 0000000000000000, RCX - 0000000000000000, RDX - 0000000000000000
RBX - FFFFFFFFFFFFFFFF, RSP - 000000007EFA7E18, RBP - 000000007EFA7EA0
RSI - 000000007E8EC018, RDI - 000000007EFC6938
R8 - 0000000000000000, R9 - 0000000003041001, R10 - 000000000000003C
R11 - 000000007EFBF5F8, R12 - 000000007EFA7E98, R13 - 0000000000000001
R14 - 000000008000F880, R15 - 000000008000F840
DS - 0000000000000030, ES - 0000000000000030, FS - 0000000000000030
GS - 0000000000000030, SS - 0000000000000030
CR0 - 0000000080010033, CR2 - 0000000000000000, CR3 - 000000007EC01000
CR4 - 0000000000000668, CR8 - 0000000000000000
DR0 - 0000000000000000, DR1 - 0000000000000000, DR2 - 0000000000000000
DR3 - 0000000000000000, DR6 - 00000000FFFF0FF0, DR7 - 0000000000000400
GDTR - 000000007E9E2000 0000000000000047, LDTR - 0000000000000000
IDTR - 000000007E5B7018 0000000000000FFF, TR - 0000000000000000
FXSAVE_STATE - 000000007EFA7A70
!!!! Can't find image information. !!!!



I don't use a boot loader on these VMs, but use the following section in the VM's libvirt configuration:

<os firmware="efi">
<type arch="x86_64" machine="pc-q35-7.1">hvm</type>
<kernel>/var/lib/libvirt/boot/vmlinuz-linux-hardened</kernel>
<initrd>/var/lib/libvirt/boot/initramfs-linux-hardened.img</initrd>
<cmdline>root=/dev/vda rootfstype=btrfs rootflags=compress=zstd,subvol=/archlinux rw console=ttyS0,115200 add_efi_memmap intel_iommu=on lockdown=confidentiality usbcore.nousb</cmdline>
<bootmenu enable="no"/>
</os>

I've found two possible solutions for the problem:

a) Shut the VM down, then run something like
cat cp /usr/share/edk2/ovmf-4m/OVMF_VARS.fd > /var/lib/libvirt/qemu/nvram/nameofyourvirtualmachine_VARS.fd
Then start the VM again.
This solution results in the VM using the new 4M UEFI image with a 528K configuration storage file, but has the adverse side effect of loosing/resetting all your existing VM-specific EFI settings, EFI variables, etc for that VM.



b) Shut the VM down, then use "virsh edit nameofyourvirtualmachine" or virt-manager to edit the VM's XML definition/configuration.
Replace the line

<os firmware="efi">

with

<os>

and inside the <os> element, insert/add something like the following two lines:
<loader readonly='yes' type='pflash'>/usr/share/edk2-ovmf/x64/OVMF_CODE.secboot.fd</loader>
<nvram>/var/lib/libvirt/qemu/nvram/nameofyourvirtualmachine_VARS.fd</nvram>

Then start the VM again.
This solution results in the VM using the old 2M UEFI image with a 128K configuration storage file, and has the advantage of keeping all your existing VM-specific EFI settings, EFI variables, etc for that VM. However, if you're running Windows 10 or Windows 11 inside your VM, recent Windows updates might require you to use solution A.

@kgizdov: Please make sure to move the new files to the /usr/share/edk2-ovmf/ dir before moving this to [extra].

@kgizdov: If this is better fixed with the 4M version of the firmware, we should just ship that then.

However, this will also come with a reset of the vars of those machines. It's a bit unclear how to best proceed here.
I'm not running any windows vms, so I don't really care, but users will.

I have moved the 4M versions of the files to their (more correct) location below /usr/share/edk2-ovmf/ to adhere to our packaging guidelines.

When looking at the issues people would be facing all across the board (not just for specific versions of windows 10/11), it seemed better to provide the 4M versions separately.
This way people should not run into problems out-of-the-box, but we should add the information that Pascal is mentioning to the wiki somewhere.

@dvzrv: Thank you! I think this can be considered fixed. The new version works wonderfully.