On Wed, 17 Jan 2024 at 14:29, Gerd Hoffmann <kra...@redhat.com> wrote: > > On Wed, Jan 17, 2024 at 01:16:34PM +0300, Michael Tokarev wrote: > > 15.01.2024 13:20, Gerd Hoffmann : > > > Hi, > > > > > > > PS: when are we likely to be able to update to a proper released > > > > EDK2 ? Running with a git snapshot isn't ideal, so if we can > > > > move to an EDK2 release version within this QEMU cycle that would > > > > be nice. > > > > > > Next release should be tagged by end of February, so if the qemu 9.0 > > > schedule is simliar to the 8.0 schedule this is before soft freeze > > > and an update should be no problem. > > > > So, should we pick this up for 8.2.1, or wait till next release of edk2 ? > > > > The thing here is that for (some) downstreams, edk2 is a separate package, > > so if qemu relies on changed edk2, it should be there before qemu-side > > changes can be added. So if we pick this patchset up for 8.2.1, it might > > be a bit surprising for downstreams. > > It's not that there changed something in the edk2 <-> qemu interfaces. > This build contains a workaround for the current shim.efi clusterf*ck. > > The tl;dr version: The build is compiled with the (very recently added) > PcdUninstallMemAttrProtocol=TRUE option to workaround a bug in shim.efi. > > The extra long version: > https://www.kraxel.org/blog/2023/12/uefi-nx-linux-boot/ > > Picking this up for 8.2.1 makes life easier for the downstreams which do > not do their own firmware builds but ship the qemu prebuilds instead.
On the other side of the scales, it's a bit unexpected for a stable-branch update to include "unreleased version of EDK binaries" (rather than, say, "same version of EDK binaries but with one specific fix"). So I can see the argument for waiting for the tagged upstream EDK release first. thanks -- PMM
