From ce61bbdcac14629b425085aee1b03998b91bd23e Mon Sep 17 00:00:00 2001
From: Eduard Abdullin <eabdullin@almalinux.org>
Date: Wed, 12 Aug 2026 18:10:25 +0300
Subject: [PATCH] Pin the x86_64 EFI builds to the x86-64-v2 ISA baseline

iPXE pins its 32-bit build to -march=i386 but passes no -march for x86_64,
so the EFI drivers inherit the builder's GCC default, which is x86-64-v3 on
AlmaLinux 10. The -mno-mmx -mno-sse that iPXE does pass is no protection:
BMI1/BMI2 operate on general purpose registers, and GCC emits tzcnt, andn,
shlx and bzhi anyway. ipxe-roms-qemu and ipxe-bootimgs-x86 are noarch and
shared by the x86_64 and x86_64_v2 repositories, so both ship v3 code and
fail with #UD on a v2-only CPU - the EFI half of each combined option ROM
is what OVMF loads.

No patch is needed: src/Makefile.housekeeping already does
"CFLAGS += $(WORKAROUND_CFLAGS) $(EXTRA_CFLAGS)", so passing EXTRA_CFLAGS
through the spec's make_ipxe helper is enough. It is deliberately applied
to the two bin-x86_64-efi invocations only, not inside the helper itself:
bin/undionly.kpxe and bin/*.rom are i386 targets (-m32 -march=i386) and
would fail to compile. bin-arm64-efi is unaffected.

Same root cause as the edk2 side of the issue, see autopatch/edk2.

https://git.almalinux.org/rpms/edk2/issues/1
---
 config.yaml | 38 ++++++++++++++++++++++++++++++++++++++
 1 file changed, 38 insertions(+)
 create mode 100644 config.yaml

diff --git a/config.yaml b/config.yaml
new file mode 100644
index 0000000..fb35878
--- /dev/null
+++ b/config.yaml
@@ -0,0 +1,38 @@
+actions:
+  - modify_release:
+    - suffix: ".alma.1"
+      enabled: true
+
+  - changelog_entry:
+      - name: "Eduard Abdullin"
+        email: "eabdullin@almalinux.org"
+        line:
+          - "Pin the x86_64 EFI builds to the x86-64-v2 ISA baseline"
+
+  # iPXE pins its 32-bit build to -march=i386 (src/arch/i386/Makefile) but passes
+  # no -march for x86_64 (src/arch/x86_64/Makefile has only -m64 -mno-mmx
+  # -mno-sse), so the EFI drivers inherit the builder's GCC default, which is
+  # x86-64-v3 on AlmaLinux 10. -mno-mmx -mno-sse does not protect against this:
+  # BMI1/BMI2 operate on general purpose registers, and GCC still emits tzcnt,
+  # andn, shlx and bzhi. The result dies with #UD on a v2-only CPU.
+  #
+  # ipxe-roms-qemu and ipxe-bootimgs-x86 are noarch, so one build is shared by
+  # the x86_64 and the x86_64_v2 repositories and has to target the lower
+  # baseline. iPXE takes the flag from the environment on its own:
+  # src/Makefile.housekeeping does "CFLAGS += $(WORKAROUND_CFLAGS) $(EXTRA_CFLAGS)".
+  #
+  # Only the bin-x86_64-efi targets may get it. bin/undionly.kpxe and bin/*.rom
+  # are built for the i386 target (-m32 -march=i386); appending -march=x86-64-v2
+  # there would override -march=i386 and break the 32-bit build, so the flag must
+  # not go inside the shared make_ipxe() helper. bin-arm64-efi is unaffected.
+  #
+  # https://git.almalinux.org/rpms/edk2/issues/1
+  - replace:
+      - target: "spec"
+        find: "make_ipxe bin-x86_64-efi/snponly.efi"
+        replace: "make_ipxe EXTRA_CFLAGS=-march=x86-64-v2 bin-x86_64-efi/snponly.efi"
+        count: 1
+      - target: "spec"
+        find: "make_ipxe CONFIG=qemu bin-x86_64-efi/${rom}.efidrv"
+        replace: "make_ipxe CONFIG=qemu EXTRA_CFLAGS=-march=x86-64-v2 bin-x86_64-efi/${rom}.efidrv"
+        count: 1