qemu, aarch64: use EDK2 from "Firmware/edk2 20231213 patches" (needed for QEMU v8.2.0)

[AkihiroSuda]

The "Firmware/edk2 20231213" patches https://lists.gnu.org/archive/html/qemu-devel/2023-12/msg01694.html
are necessary to boot most aarch64 images (except Debian, which does not use UEFI shim).

The patches are proposed for the QEMU v8.2.0 milestone, but likely to be postponed to v8.2.1.
Until the patches get accepted in the QEMU upstream, Lima fetches the patched
edk2 binary from https://gitlab.com/kraxel/qemu/-/tags/firmware%2Fedk2-20231213-pull-request.

[AkihiroSuda]

QEMU 8.2.0 is likely to be released with an incompatible version of EDK2, on 2023-12-12 or 2023-12-19:
https://gitlab.com/qemu-project/qemu/-/issues/1990#note_1688360743
https://wiki.qemu.org/Planning/8.2

We have to release a new version Lima with this PR before that.
cc @lima-vm/maintainers

[AkihiroSuda]

( Last-minute negotiation is on going here: https://lists.gnu.org/archive/html/qemu-devel/2023-12/msg01694.html )

[AkihiroSuda]

QEMU v8.2.0 will be released on 2023-12-19: https://wiki.qemu.org/Planning/8.2

If the patches (https://lists.gnu.org/archive/html/qemu-devel/2023-12/msg01694.html ) are not merged as of 2023-12-18, we will have to merge this PR and release Lima v0.19.1.

If the patches can be merged, we can just close this PR.

[jandubois]

I'm somewhat confused how these patches are related to the M3 issues on QEMU.

Are the patches necessary for most images to work at all on Apple chips, include M1 and M2, and without them QEMU 8.2.0 is broken for all distros except Debian?

But QEMU 8.1.0 is still good even without the firmware update?

And will the new firmware also fix the problem that even older QEMU versions don't work on M3? Or is that a completely separate issue?

And finally (although maybe not interesting): will the new firmware fix the M3 problem on older QEMU versions, like 8.0.0 or 8.1.0? Or does the new firmware require the new QEMU version?

[AkihiroSuda]

I'm somewhat confused how these patches are related to the M3 issues on QEMU.

The story is quite complicated.

tianocore/edk2#4418 (ArmPkg/ArmMmuLib AARCH64: Add missing ISB after page table update, merged on 2023-05-23) is expected to fix the issue for M3, but this revision is practically unusable for Lima (and many others) on any chip, because tianocore/edk2#4150 (Pull arm memory attr table, merged on 2023-03-17) added the implementation of EFI_MEMORY_ATTRIBUTE_PROTOCOL, which makes almost all existing Linux distro images (except Debian, which does not use UEFI shim) unbootable, due to a broken support for EFI_MEMORY_ATTRIBUTE_PROTOCOL on the UEFI shim side.
(The UEFI shim issue was fixed in rhboot/shim#539 , but the fix is only present in the main branch of the shim and not cherry-picked by any well-known distro.)

The QEMU patches (https://lists.gnu.org/archive/html/qemu-devel/2023-12/msg01694.html) bumps up EDK2
to include tianocore/edk2#5104 (ArmVirtPkg: Allow EFI memory attributes protocol to be disabled, merged on 2023-12-12) and enables the PcdUninstallMemAttrProtocol build option to uninstall EFI_MEMORY_ATTRIBUTE_PROTOCOL so as to rescue us.

This revision should work on any chip, but I only tested it on M2 Pro.

Are the patches necessary for most images to work at all on Apple chips, include M1 and M2, and without them QEMU 8.2.0 is broken for all distros except Debian?

Yes, necessary. Without the patches, QEMU v8.2.0-rc4 cannot boot most images on any chip.

But QEMU 8.1.0 is still good even without the firmware update?

Yes, still good, except on M3.

And will the new firmware also fix the problem that even older QEMU versions don't work on M3? Or is that a completely separate issue?

Separate.

• 2023-03-17 (Pull arm memory attr table tianocore/edk2#4150): broke compatibility with existing releases of UEFI shim (on any chip)
• 2023-05-23 (ArmPkg/ArmMmuLib AARCH64: Add missing ISB after page table update tianocore/edk2#4418): fixed M3 incompatibility
• 2023-12-12 (ArmVirtPkg: Allow EFI memory attributes protocol to be disabled tianocore/edk2#5104): provided a workaround for the UEFI shim issue

And finally (although maybe not interesting): will the new firmware fix the M3 problem on older QEMU versions, like 8.0.0 or 8.1.0? Or does the new firmware require the new QEMU version?

The former, IIUC
(I don't have M3 to verify)

[jandubois]

The former, IIUC

So (given that Rancher Desktop bundles QEMU 8.0.0 with the aarch64 version right now, and doesn't care about which version from homebrew is installed), we should be able to just replace the firmware in 8.0.0 and things should continue to work on M1 and M2, and start working for M3? That sounds great, if true.

(I don't have M3 to verify)

Yeah, me neither. Making it the second Apple related issue I cannot reproduce and verify (the mcxalr issue is also still unresolved with our latest attempts). Maybe I can find someone who bought an M3 as their personal machine...

[AkihiroSuda]

we should be able to just replace the firmware in 8.0.0 and things should continue to work on M1 and M2, and start working for M3? That sounds great, if true.

I believe so.

[AkihiroSuda]

The patches https://lists.gnu.org/archive/html/qemu-devel/2023-12/msg01694.html aren't likely going to be included in QEMU v8.2.0, so I'll merge this PR and release Lima v0.19.1 today.