Quite a big report, don't really know how to split it. This series of patches adds a bit of stuff, I'll go one by one: 0001-devel-edk2-tools-New-port.patch: - Adds the devel/edk2-tools port, mainly to avoid repeatedly building EDK2s C utilities for each flavor. Also, one of the reasons I'm splitting utils off into a separate port is the EfiRom utility can be used for converting drivers extracted from vendor UEFI firmware into bhyve-compatible OpROMs. 0002-sysutils-edk2-Update-to-202605.patch: - Bumps the sysutils/edk2 port's version to g202605, many patches included. - Brings back the MemAttr protocol; let's not disregard the UEFI standards. - Changes the compiler to LLVM from ports (host LLVM may lack alien archs). - Adds two new flavors: xen_aarch64 and qemu_aarch64 and removes qemu_i386. - Heavily reformats the Makefile for easier switching between LLVM and GCC. - No longer installs firmware into legacy paths for sysutils/bhyve-firmware. - No longer resizes your terminal emulator when connecting over serial. 0003-sysutils-edk2-legacy-New-port.patch: - Repurposes the updated sysutils/edk2 Makefile with little changes. - Brings back the pre-update g202305 version of the sysutils/edk2 port. - Adds support for x2APIC that bhyve provides with the '-x' option. 0004-sysutils-bhyve-firmware-Use-sysutils-edk2-legacy.patch: - Points sysutils/bhyve-firmware to sysutils/edk2-legacy. Patch 0001 can be applied by its own, patches 0002, 0003 and 0004 must be applied all at the same time and 0002 with 0003 depend on 0001. The sysutils/edk2 package update also comes with a couple of upstreamed patches from me that bring back the UEFI Shell and iPXE Boot (big sorry, did not notice they was gone from the previous update!) and bump the modules closer to QEMU's EDK2. This means the '-x' option works now since we have x2APIC! Sadly, EDK2 on bhyve still relies on an HPET timer rather than APIC, even though APIC timer support exists. When using an APIC timer, everything UEFI related seems to count time about five times slower than it should. This might of course be an AMD-only issue or even something specific to my setup, I have only tested an APIC build on a single machine. Also, it builds EDK2 with HTTPS (no HTTP) boot and TLS. (I gave up on making all the changes lines exactly 83 characters long) (If you don't see all the patches attached right away, I might still be uploading them) Sorry for the update taking so long! This was quite a journey!
Created attachment 271626 [details] patch 0001: devel/edk2-tools: New port
Created attachment 271627 [details] patch 0002: sysutils/edk2: Update to 202605
Created attachment 271628 [details] patch 0003: sysutils/edk2-legacy: New patch
Created attachment 271629 [details] patch 0004: sysutils/bhyve-firmware: Use sysutils/edk2-legacy
Massive, thank you! There are several open issues (partially reported by me), can you link them here as well?
(In reply to Alexey from comment #2) (In reply to Michael Osipov from comment #5) Do I just link the issues in a comment here? This series of patches fixes: bug #294520 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=294520 bug #292897 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=292897 bug #294540 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=294540 bug #294516 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=294516
(In reply to Alexey from comment #6) Good, if your change fixes all of them then you can put the bug ids in the "Depends" field.
(In reply to Michael Osipov from comment #7) I'm confused. For example, saying 295943 depends on 292897 indicates that 292897 must be fixed before 295943 can be finished. Similarly for 294516, 294520, and 294540. It does not indicate that 295943 fixes those other defects. Also, saying that 292897 blocks 295943 indicates that 292897 needs to be fixed to start on 295943. As near as I can tell, the proposal here is to simply update to 202605 --and that might fix some or all of the other listed defects, making any such "overcome by events" via the event being the upgrade instead of targeted fixes of the older version.
(In reply to Mark Millard from comment #8) As far as I can tell Alexey did the opposite way which I did not tell. My understand that this update should salvage basically all of the issues I have mentioned. So this one block the rest (needs to be verified of course).
(In reply to Michael Osipov from comment #9) Oh oops
I'm not sure I understand the -legacy separation part of these changes. IIUC, if I update my system from a repo built with this changes, my /usr/local/share/uefi-firmware/BHYVE_UEFI.fd firmware will be gone because edk2-bhyve now uses different names. So all my UEFI VMs will get broken. And if I happen to have the bhyve-firmware package installed, my VMs will continue working, but it'll actually downgrade from g202506 to g202308. Feels like it needs an UPDATING entry at least. Probably it also makes sense to make bhyve-firmware depend on both legacy and current versions. I also wonder if version based ports will be more flexible than the -legacy/-current separation, e.g. edk2202308, edk2202506 etc (look a bit weird because of the "2" in "edk2" though).
Created attachment 272334 [details] patch 0002: sysutils/edk2: Update to 202605 Updated patch that installs the new edk2 in the legacy path like it was before.
Created attachment 272335 [details] patch 0003: sysutils/edk2-legacy: New port Updated patch that only appends to bhyve-firmware instead of overwriting sysutils/edk2 for itself. Does not install itself in LOCALBASE/share/uefi-firmware/BHYVE_UEFI* as the latest port does that.
Static review: > Changes the compiler to LLVM from ports (host LLVM may lack alien archs). Can this please optional only for alien archs? Most will not need it, but will be forced to download or even worse build LLVM from ports > No longer resizes your terminal emulator when connecting over serial. How is this fixed? > 0003-sysutils-edk2-legacy-New-port.patch Is this for older OSes which aren't supported by newer versions of the EDK2 anymore? > patch 0001: devel/edk2-tools: New port Why not use DISABLE_MAKE_JOBS instead of do-build target? TOOLIN= ${STAGEDIR}${PREFIX}/libexec/${PORTNAME} STAGEDIR should rather be used in the actual targets, not here, this path should be clean of staging do-install: Rather than cp we have explicitly ${INSTALL_*} commands, please have a look. Does it really make sense to install them to libexec/edk2-tools/C/ although they are standalone? In other words: Is there any use for them outside of the EDK2 world? Will go over to compilation.
Trying to build in poudriere fails with: 236 ===== env: NO_DEPENDS=yes USER=root UID=0 GID=0 237 ===> Patching for edk2-legacy-bhyve-g202308 238 ===> Applying distribution patches for edk2-legacy-bhyve-g202308 239 ===> Applying FreeBSD patches for edk2-legacy-bhyve-g202308 from /usr/ports/sysutils/edk2-legacy/files 240 2 out of 2 hunks failed--saving rejects to OvmfPkg/Bhyve/AcpiPlatformDxe/AcpiPlatform.c.rej 241 ===> FAILED Applying FreeBSD patch-OvmfPkg_Bhyve_AcpiPlatformDxe_AcpiPlatform.c 242 ===> FAILED to apply cleanly FreeBSD patch(es) patch-OvmfPkg_Bhyve_AcpiPlatformDxe_AcpiPlatform.c 243 *** Error code 1
(In reply to Michael Osipov from comment #15) Oof. This is definitely because of DOS line endings.
(In reply to Michael Osipov from comment #14) Thanks, will take a look tomorrow, need to take a good sleep right now.
(In reply to Michael Osipov from comment #14) 1. Is it safe to just remove the LLVM dependency and assume that host's LLVM supports alien arch's? 2. "patch-MdeModulePkg_Universal_Console_TerminalDxe_TerminalConOut.c" patches out an escape sequence EDK2 sends that makes some terminal emulators resize the window to massive sizes. 3. Yep, this is the older version of EDK2 that supports 32-bit EFI OSes. I could've went for a mid-2025 release, but I don't want to risk breaking something else, so just bring back the original 2023 one. 4. This (edk2-tools) is my first from-scratch port, sorry. > Does it really make sense to install them to libexec/edk2-tools/C/ although they are standalone? In other words: Is there any use for them outside of the EDK2 world? I use EfiRom for converting some PCI drivers extracted from vendor UEFI firmware to bhyve-compatible OpROMs for GPU passthrough. I also packaged it separately to avoid compiling the tools for each flavor, but honestly it doesn't take that long. Going to remove it.
(In reply to Alexey from comment #18) > 1. Is it safe to just remove the LLVM dependency and assume that host's LLVM supports alien arch's? I don't know. Did you try with base LLVM for those archs? Alternatively, we can wait for the first reports and then we know for sure. > "patch-MdeModulePkg_Universal_Console_TerminalDxe_TerminalConOut.c" patches out an escape sequence EDK2 sends that makes some terminal emulators resize the window to massive sizes. Is this really a solution or a workaround? As far as I understood the resize change is that UEFI GOP is inspected and the largest value is selected. > Yep, this is the older version of EDK2 that supports 32-bit EFI OSes. > I could've went for a mid-2025 release, but I don't want to risk breaking something else, so just bring back the original 2023 one. I see, maybe a pkg-install should tell why this -legacy port exist and when it makes sense to use it or not. > I use EfiRom for converting some PCI drivers extracted from vendor UEFI firmware to bhyve-compatible OpROMs for GPU passthrough. I don't mind the tools being separate as long as you see a reason to have the separately. Keep them, imho.
FreeBSD uses LLVM to build clang, ld.lld, and the like but does not distribute LLVM itself. I'm wondering if the wording here was intending something more like clang-related toolchain rather than general LLVM. In case it was just clang related, for a main/CURRENT context there is just: # cc --print-targets Registered Targets: aarch64 - AArch64 (little endian) aarch64_32 - AArch64 (little endian ILP32) aarch64_be - AArch64 (big endian) arm - ARM arm64 - ARM64 (little endian) arm64_32 - ARM64 (little endian ILP32) armeb - ARM (big endian) ppc32 - PowerPC 32 ppc32le - PowerPC 32 LE ppc64 - PowerPC 64 ppc64le - PowerPC 64 LE riscv32 - 32-bit RISC-V riscv64 - 64-bit RISC-V thumb - Thumb thumbeb - Thumb (big endian) x86 - 32-bit X86: Pentium-Pro and above x86-64 - 64-bit X86: EM64T and AMD64 Context information: # cc -v FreeBSD clang version 21.1.8 (https://github.com/llvm/llvm-project.git llvmorg-21.1.8-0-g2078da43e25a) Target: x86_64-unknown-freebsd16.0 Thread model: posix InstalledDir: /usr/bin Build config: +assertions # uname -apKU FreeBSD 7950X3D-ZFS 16.0-CURRENT FreeBSD 16.0-CURRENT main-n286573-bea6f7d02dfb GENERIC-NODEBUG amd64 amd64 1600018 1600018 (That is from a upstream pkgbase distribution install/update sequence.)
Same here: $ uname -apKU FreeBSD deblndw011x.innomotics.net 14.4-STABLE FreeBSD 14.4-STABLE 12b941265 GENERIC amd64 amd64 1404501 1404501 $ cc -v FreeBSD clang version 21.1.8 (https://github.com/llvm/llvm-project.git llvmorg-21.1.8-0-g2078da43e25a) Target: x86_64-unknown-freebsd14.4 Thread model: posix InstalledDir: /usr/bin $ cc --print-targets Registered Targets: aarch64 - AArch64 (little endian) aarch64_32 - AArch64 (little endian ILP32) aarch64_be - AArch64 (big endian) arm - ARM arm64 - ARM64 (little endian) arm64_32 - ARM64 (little endian ILP32) armeb - ARM (big endian) ppc32 - PowerPC 32 ppc32le - PowerPC 32 LE ppc64 - PowerPC 64 ppc64le - PowerPC 64 LE riscv32 - 32-bit RISC-V riscv64 - 64-bit RISC-V thumb - Thumb thumbeb - Thumb (big endian) x86 - 32-bit X86: Pentium-Pro and above x86-64 - 64-bit X86: EM64T and AMD64
(In reply to Michael Osipov from comment #21) # freebsd-version 14.4-RELEASE-p6 is still at: # cc -v FreeBSD clang version 19.1.7 (https://github.com/llvm/llvm-project.git llvmorg-19.1.7-0-gcd708029e0b2) Target: x86_64-unknown-freebsd14.4 Thread model: posix InstalledDir: /usr/bin which also reports: # cc --print-targets Registered Targets: aarch64 - AArch64 (little endian) aarch64_32 - AArch64 (little endian ILP32) aarch64_be - AArch64 (big endian) arm - ARM arm64 - ARM64 (little endian) arm64_32 - ARM64 (little endian ILP32) armeb - ARM (big endian) ppc32 - PowerPC 32 ppc32le - PowerPC 32 LE ppc64 - PowerPC 64 ppc64le - PowerPC 64 LE riscv32 - 32-bit RISC-V riscv64 - 64-bit RISC-V thumb - Thumb thumbeb - Thumb (big endian) x86 - 32-bit X86: Pentium-Pro and above x86-64 - 64-bit X86: EM64T and AMD64