Re: Re: [PULL 0/6] Firmware/edk2 20231213 patches

[Peter Maydell]

On Wed, 17 Jan 2024 at 14:29, Gerd Hoffmann <kraxel@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