The following changes since commit f0a5a31c33a8109061c2493e475c8a2f4d022432:

  Update version for v9.2.0-rc0 release (2024-11-13 21:44:45 +0000)

are available in the Git repository at:

  https://gitlab.com/kraxel/qemu.git tags/firmware-20241114-pull-request

for you to fetch changes up to 5916a3b20fdbfbfc2f987f1121e945100c8c3cd2:

  x86/loader: add -shim option (2024-11-14 11:55:39 +0100)

----------------------------------------------------------------
loader: fix efi binary loading via -kernel
loader: support secure boot verification with direct kernel boot

----------------------------------------------------------------

Gerd Hoffmann (5):
  vl: fix qemu_validate_options() indention
  x86/loader: only patch linux kernels
  x86/loader: read complete kernel
  x86/loader: expose unpatched kernel
  x86/loader: add -shim option

 include/hw/boards.h  |  1 +
 hw/core/machine.c    | 20 ++++++++++++++++++++
 hw/i386/x86-common.c | 32 ++++++++++++++++++++++++++------
 system/vl.c          | 25 +++++++++++++++++--------
 qemu-options.hx      |  7 +++++++
 5 files changed, 71 insertions(+), 14 deletions(-)

-- 
2.47.0

On Thu, Nov 14, 2024 at 12:00:56PM +0100, Gerd Hoffmann wrote:
> The following changes since commit f0a5a31c33a8109061c2493e475c8a2f4d022432:
> 
>   Update version for v9.2.0-rc0 release (2024-11-13 21:44:45 +0000)
> 
> are available in the Git repository at:
> 
>   https://gitlab.com/kraxel/qemu.git tags/firmware-20241114-pull-request
> 
> for you to fetch changes up to 5916a3b20fdbfbfc2f987f1121e945100c8c3cd2:
> 
>   x86/loader: add -shim option (2024-11-14 11:55:39 +0100)
> 
> ----------------------------------------------------------------
> loader: fix efi binary loading via -kernel
> loader: support secure boot verification with direct kernel boot

Hard feature freeze was two days ago, so I would have thought
the new secure boot feature should wait until 10.0 cycle ?

Their commits say they depend on new OVMF features and we've
not updated the OVMF binaries in this cycle, so do we even
have the OVMF feature needed for this to work[1] ?

With regards,
Daniel

[1] admittedly not an issue for distros packaging ovmf separately
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

On Thu, Nov 14, 2024 at 11:10:11AM +0000, Daniel P. Berrangé wrote:
> On Thu, Nov 14, 2024 at 12:00:56PM +0100, Gerd Hoffmann wrote:
> > The following changes since commit f0a5a31c33a8109061c2493e475c8a2f4d022432:
> > 
> >   Update version for v9.2.0-rc0 release (2024-11-13 21:44:45 +0000)
> > 
> > are available in the Git repository at:
> > 
> >   https://gitlab.com/kraxel/qemu.git tags/firmware-20241114-pull-request
> > 
> > for you to fetch changes up to 5916a3b20fdbfbfc2f987f1121e945100c8c3cd2:
> > 
> >   x86/loader: add -shim option (2024-11-14 11:55:39 +0100)
> > 
> > ----------------------------------------------------------------
> > loader: fix efi binary loading via -kernel
> > loader: support secure boot verification with direct kernel boot
> 
> Hard feature freeze was two days ago, so I would have thought
> the new secure boot feature should wait until 10.0 cycle ?

Patches have been posted back in September.  This PR is a bit late
because I was offline in October, and also because I didn't realize we
are in freeze already due to being active mostly in edk2 these days.

So, if an exception is out if question I'll have to wait until 10.0
opens I guess ...

> Their commits say they depend on new OVMF features and we've
> not updated the OVMF binaries in this cycle, so do we even
> have the OVMF feature needed for this to work[1] ?

Nope.  I have a branch ready.  The plan is to submit that once the qemu
changes are accepted.  edk2 is in freeze too, so this will not make the
edk2 2024-11 stable tag.  If all goes well it'll land in 2025-02, which
we should be able to put into qemu 10.0

take care,
  Gerd

On Thu, 14 Nov 2024 at 11:33, Gerd Hoffmann <kraxel@redhat.com> wrote:
>
> On Thu, Nov 14, 2024 at 11:10:11AM +0000, Daniel P. Berrangé wrote:
> > On Thu, Nov 14, 2024 at 12:00:56PM +0100, Gerd Hoffmann wrote:
> > > The following changes since commit f0a5a31c33a8109061c2493e475c8a2f4d022432:
> > >
> > >   Update version for v9.2.0-rc0 release (2024-11-13 21:44:45 +0000)
> > >
> > > are available in the Git repository at:
> > >
> > >   https://gitlab.com/kraxel/qemu.git tags/firmware-20241114-pull-request
> > >
> > > for you to fetch changes up to 5916a3b20fdbfbfc2f987f1121e945100c8c3cd2:
> > >
> > >   x86/loader: add -shim option (2024-11-14 11:55:39 +0100)
> > >
> > > ----------------------------------------------------------------
> > > loader: fix efi binary loading via -kernel
> > > loader: support secure boot verification with direct kernel boot
> >
> > Hard feature freeze was two days ago, so I would have thought
> > the new secure boot feature should wait until 10.0 cycle ?
>
> Patches have been posted back in September.  This PR is a bit late
> because I was offline in October, and also because I didn't realize we
> are in freeze already due to being active mostly in edk2 these days.
>
> So, if an exception is out if question I'll have to wait until 10.0
> opens I guess ...
>
> > Their commits say they depend on new OVMF features and we've
> > not updated the OVMF binaries in this cycle, so do we even
> > have the OVMF feature needed for this to work[1] ?
>
> Nope.  I have a branch ready.  The plan is to submit that once the qemu
> changes are accepted.  edk2 is in freeze too, so this will not make the
> edk2 2024-11 stable tag.  If all goes well it'll land in 2025-02, which
> we should be able to put into qemu 10.0

If we aren't landing the firmware side until QEMU 10.0 either
then I think I agree with Daniel that the QEMU-side new
feature work also should wait until 10.0.

(I plan to try to be quite conservative with the release schedule
this cycle, because we don't have a lot of time between when
it's supposed to complete and the Christmas holidays, so we
can't afford to overrun the nominal release date by more than
a week.)

thanks
-- PMM