| Message ID | 20231213105026.1944656-1-kraxel@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Wed, Dec 13, 2023 at 11:50:12AM +0100, Gerd Hoffmann wrote: > The following changes since commit 9c74490bff6c8886a922008d0c9ce6cae70dd17e: > > Update version for v8.2.0-rc3 release (2023-12-06 14:34:20 -0500) > > are available in the Git repository at: > > https://gitlab.com/kraxel/qemu.git tags/firmware/edk2-20231213-pull-request > > for you to fetch changes up to 704f7cad5105246822686f65765ab92045f71a3b: > > tests/acpi: disallow tests/data/acpi/virt/SSDT.memhp changes (2023-12-13 11:23:11 +0100) > > ---------------------------------------------------------------- > edk2: update to git snapshot (maybe for-8.2) > > This updates edk2 to git master as of today. This picks up a patch > (merged only yesterday, that's why this last-minute PR) which allows to > work around a bug in shim, and enables that workaround in the qemu > firmware builds. > > This solves a real-world problem on arm hardware, walk over to > https://gitlab.com/qemu-project/qemu/-/issues/1990 to see the details. > > Merging this firmware update that close to the 8.2 release clearly is > not without risks. If I get a 'no', I'm not going to complain. > > That said I'm not aware of any bugs, and landing this in 8.2.0 would > make a bunch of folks hanging around in issue 1990 very happy. > > Alternative plan would be to merge this after the release, give it some > time for testing, and assuming everything goes well schedule a backport > for 8.2.1 Ping. As expected this missed the 8.2 boat. Now the devel tree is open again and people are back from xmas + new year vacations, can this be picked up for master and eventually 8.2-stable? thanks, Gerd
On Thu, 11 Jan 2024 at 14:01, Gerd Hoffmann <kraxel@redhat.com> wrote: > > On Wed, Dec 13, 2023 at 11:50:12AM +0100, Gerd Hoffmann wrote: > > The following changes since commit 9c74490bff6c8886a922008d0c9ce6cae70dd17e: > > > > Update version for v8.2.0-rc3 release (2023-12-06 14:34:20 -0500) > > > > are available in the Git repository at: > > > > https://gitlab.com/kraxel/qemu.git tags/firmware/edk2-20231213-pull-request > > > > for you to fetch changes up to 704f7cad5105246822686f65765ab92045f71a3b: > > > > tests/acpi: disallow tests/data/acpi/virt/SSDT.memhp changes (2023-12-13 11:23:11 +0100) > > > > ---------------------------------------------------------------- > > edk2: update to git snapshot (maybe for-8.2) > > > > This updates edk2 to git master as of today. This picks up a patch > > (merged only yesterday, that's why this last-minute PR) which allows to > > work around a bug in shim, and enables that workaround in the qemu > > firmware builds. > > > > This solves a real-world problem on arm hardware, walk over to > > https://gitlab.com/qemu-project/qemu/-/issues/1990 to see the details. > > > > Merging this firmware update that close to the 8.2 release clearly is > > not without risks. If I get a 'no', I'm not going to complain. > > > > That said I'm not aware of any bugs, and landing this in 8.2.0 would > > make a bunch of folks hanging around in issue 1990 very happy. > > > > Alternative plan would be to merge this after the release, give it some > > time for testing, and assuming everything goes well schedule a backport > > for 8.2.1 > > Ping. > > As expected this missed the 8.2 boat. Now the devel tree is open again > and people are back from xmas + new year vacations, can this be picked > up for master and eventually 8.2-stable? I can queue it, sure. Do we need to respin it to add cc: qemu-stable tags, or can it be applied as-is ? -- PMM
On Thu, 11 Jan 2024 at 15:52, Peter Maydell <peter.maydell@linaro.org> wrote: > > On Thu, 11 Jan 2024 at 14:01, Gerd Hoffmann <kraxel@redhat.com> wrote: > > > > On Wed, Dec 13, 2023 at 11:50:12AM +0100, Gerd Hoffmann wrote: > > > The following changes since commit 9c74490bff6c8886a922008d0c9ce6cae70dd17e: > > > > > > Update version for v8.2.0-rc3 release (2023-12-06 14:34:20 -0500) > > > > > > are available in the Git repository at: > > > > > > https://gitlab.com/kraxel/qemu.git tags/firmware/edk2-20231213-pull-request > > > > > > for you to fetch changes up to 704f7cad5105246822686f65765ab92045f71a3b: > > > > > > tests/acpi: disallow tests/data/acpi/virt/SSDT.memhp changes (2023-12-13 11:23:11 +0100) > > > > > > ---------------------------------------------------------------- > > > edk2: update to git snapshot (maybe for-8.2) > > > > > > This updates edk2 to git master as of today. This picks up a patch > > > (merged only yesterday, that's why this last-minute PR) which allows to > > > work around a bug in shim, and enables that workaround in the qemu > > > firmware builds. > > > > > > This solves a real-world problem on arm hardware, walk over to > > > https://gitlab.com/qemu-project/qemu/-/issues/1990 to see the details. > > > > > > Merging this firmware update that close to the 8.2 release clearly is > > > not without risks. If I get a 'no', I'm not going to complain. > > > > > > That said I'm not aware of any bugs, and landing this in 8.2.0 would > > > make a bunch of folks hanging around in issue 1990 very happy. > > > > > > Alternative plan would be to merge this after the release, give it some > > > time for testing, and assuming everything goes well schedule a backport > > > for 8.2.1 > > > > Ping. > > > > As expected this missed the 8.2 boat. Now the devel tree is open again > > and people are back from xmas + new year vacations, can this be picked > > up for master and eventually 8.2-stable? > > I can queue it, sure. Do we need to respin it to add cc: qemu-stable > tags, or can it be applied as-is ? ...PS did you mean to cc qemu-stable, not the nonexistent edk2-stable on this pullreq email? thanks -- PMM
On Thu, Jan 11, 2024 at 04:02:38PM +0000, Peter Maydell wrote: > On Thu, 11 Jan 2024 at 15:52, Peter Maydell <peter.maydell@linaro.org> wrote: > > > > On Thu, 11 Jan 2024 at 14:01, Gerd Hoffmann <kraxel@redhat.com> wrote: > > > > > > Ping. > > > > > > As expected this missed the 8.2 boat. Now the devel tree is open again > > > and people are back from xmas + new year vacations, can this be picked > > > up for master and eventually 8.2-stable? > > > > I can queue it, sure. Do we need to respin it to add cc: qemu-stable > > tags, or can it be applied as-is ? > > ...PS did you mean to cc qemu-stable, not the nonexistent edk2-stable > on this pullreq email? Yes, Cc'ing qemu-stable was the intention, thanks for fixing it up. I'd leave it to the stable maintainer(s). If they prefer a respin with Cc qemu-stable added to all patches I surely can do that. If being notified with this reply is good enough I'm happy too. take care, Gerd
On Thu, 11 Jan 2024 at 16:28, Gerd Hoffmann <kraxel@redhat.com> wrote: > > On Thu, Jan 11, 2024 at 04:02:38PM +0000, Peter Maydell wrote: > > On Thu, 11 Jan 2024 at 15:52, Peter Maydell <peter.maydell@linaro.org> wrote: > > > > > > On Thu, 11 Jan 2024 at 14:01, Gerd Hoffmann <kraxel@redhat.com> wrote: > > > > > > > > Ping. > > > > > > > > As expected this missed the 8.2 boat. Now the devel tree is open again > > > > and people are back from xmas + new year vacations, can this be picked > > > > up for master and eventually 8.2-stable? > > > > > > I can queue it, sure. Do we need to respin it to add cc: qemu-stable > > > tags, or can it be applied as-is ? > > > > ...PS did you mean to cc qemu-stable, not the nonexistent edk2-stable > > on this pullreq email? > > Yes, Cc'ing qemu-stable was the intention, thanks for fixing it up. > > I'd leave it to the stable maintainer(s). If they prefer a respin with > Cc qemu-stable added to all patches I surely can do that. If being > notified with this reply is good enough I'm happy too. Well, it all made it through the CI fine, and I think MJT is fairly flexible about stable- notifications, so I'm going to push this merge to git. Applied, thanks. Please update the changelog at https://wiki.qemu.org/ChangeLog/9.0 for any user-visible changes. -- PMM
11.01.2024 19:28, Gerd Hoffmann: .. > Yes, Cc'ing qemu-stable was the intention, thanks for fixing it up. > > I'd leave it to the stable maintainer(s). If they prefer a respin with > Cc qemu-stable added to all patches I surely can do that. If being > notified with this reply is good enough I'm happy too. There's no requirement to have Cc: qemu-stable tags on the patches. This tagging is only to easily find changes which are supposed to be picked up for stable, nothing more, so it's completely optional. It's a bit unusual though to have whole series in -stable. I picked up all 6 for now, let's see how it will work out. Thanks, /mjt
12.01.2024 17:27, Michael Tokarev: > There's no requirement to have Cc: qemu-stable tags on the patches. > This tagging is only to easily find changes which are supposed to be > picked up for stable, nothing more, so it's completely optional. An additional note: without this Cc by Peter, I would've never noticed this patchset. /mjt
On Fri, 12 Jan 2024 at 12:47, Peter Maydell <peter.maydell@linaro.org> wrote: > > On Thu, 11 Jan 2024 at 16:28, Gerd Hoffmann <kraxel@redhat.com> wrote: > > > > On Thu, Jan 11, 2024 at 04:02:38PM +0000, Peter Maydell wrote: > > > On Thu, 11 Jan 2024 at 15:52, Peter Maydell <peter.maydell@linaro.org> wrote: > > > > > > > > On Thu, 11 Jan 2024 at 14:01, Gerd Hoffmann <kraxel@redhat.com> wrote: > > > > > > > > > > Ping. > > > > > > > > > > As expected this missed the 8.2 boat. Now the devel tree is open again > > > > > and people are back from xmas + new year vacations, can this be picked > > > > > up for master and eventually 8.2-stable? > > > > > > > > I can queue it, sure. Do we need to respin it to add cc: qemu-stable > > > > tags, or can it be applied as-is ? > > > > > > ...PS did you mean to cc qemu-stable, not the nonexistent edk2-stable > > > on this pullreq email? > > > > Yes, Cc'ing qemu-stable was the intention, thanks for fixing it up. > > > > I'd leave it to the stable maintainer(s). If they prefer a respin with > > Cc qemu-stable added to all patches I surely can do that. If being > > notified with this reply is good enough I'm happy too. > > Well, it all made it through the CI fine, and I think MJT is > fairly flexible about stable- notifications, so I'm going to > push this merge to git. > > > Applied, thanks. > > Please update the changelog at https://wiki.qemu.org/ChangeLog/9.0 > for any user-visible changes. 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. thanks -- PMM
On Fri, 12 Jan 2024 at 16:19, Peter Maydell <peter.maydell@linaro.org> wrote: > 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. ...and for a stable backport, backporting the released version seems likely to be better than backporting the git-snapshot. -- PMM
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. take care, Gerd
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. Thanks, /mjt
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. take care, Gerd
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