Also little refactoring in preparation
to avoid code duplication.

Gerd Hoffmann (3):
  hw/nvram: add load_image_to_fw_cfg_file()
  hw/i386: switch shim loading to load_image_to_fw_cfg_file
  hw/arm: add support for shim loading

 hw/arm/boot.c             |  6 ++++++
 hw/i386/x86-common.c      | 15 ++-------------
 hw/nvram/fw_cfg.c         | 22 ++++++++++++++++++++++
 include/hw/arm/boot.h     |  1 +
 include/hw/nvram/fw_cfg.h | 15 +++++++++++++++
 5 files changed, 46 insertions(+), 13 deletions(-)

-- 
2.54.0

On Thu, 21 May 2026 at 12:28, Gerd Hoffmann <kraxel@redhat.com> wrote:
>
> Also little refactoring in preparation
> to avoid code duplication.
>
> Gerd Hoffmann (3):
>   hw/nvram: add load_image_to_fw_cfg_file()
>   hw/i386: switch shim loading to load_image_to_fw_cfg_file
>   hw/arm: add support for shim loading

Any chance of some information on what this is?

There's no real description of it in the commit messages,
and as far as I can see the only documentation we have
is the rather cryptic:
  -shim shim.efi
    Use ‘shim.efi’ to boot the kernel
in the "Invocation" section...

thanks
-- PMM

On Thu, May 28, 2026 at 03:28:05PM +0100, Peter Maydell wrote:
> On Thu, 21 May 2026 at 12:28, Gerd Hoffmann <kraxel@redhat.com> wrote:
> >
> > Also little refactoring in preparation
> > to avoid code duplication.
> >
> > Gerd Hoffmann (3):
> >   hw/nvram: add load_image_to_fw_cfg_file()
> >   hw/i386: switch shim loading to load_image_to_fw_cfg_file
> >   hw/arm: add support for shim loading
> 
> Any chance of some information on what this is?

Ping.  The doc update with additional info is merged,
this isn't yet.

Do you want take this through the arm queue?
Alternatively I can merge this via firmware queue.

thanks,
  Gerd

On Thu, 2 Jul 2026 at 10:45, Gerd Hoffmann <kraxel@redhat.com> wrote:
>
> On Thu, May 28, 2026 at 03:28:05PM +0100, Peter Maydell wrote:
> > On Thu, 21 May 2026 at 12:28, Gerd Hoffmann <kraxel@redhat.com> wrote:
> > >
> > > Also little refactoring in preparation
> > > to avoid code duplication.
> > >
> > > Gerd Hoffmann (3):
> > >   hw/nvram: add load_image_to_fw_cfg_file()
> > >   hw/i386: switch shim loading to load_image_to_fw_cfg_file
> > >   hw/arm: add support for shim loading
> >
> > Any chance of some information on what this is?
>
> Ping.  The doc update with additional info is merged,
> this isn't yet.
>
> Do you want take this through the arm queue?
> Alternatively I can merge this via firmware queue.

I've applied it to target-arm.next; thanks.

-- PMM

On Thu, May 28, 2026 at 03:28:05PM +0100, Peter Maydell wrote:
> On Thu, 21 May 2026 at 12:28, Gerd Hoffmann <kraxel@redhat.com> wrote:
> >
> > Also little refactoring in preparation
> > to avoid code duplication.
> >
> > Gerd Hoffmann (3):
> >   hw/nvram: add load_image_to_fw_cfg_file()
> >   hw/i386: switch shim loading to load_image_to_fw_cfg_file
> >   hw/arm: add support for shim loading
> 
> Any chance of some information on what this is?

It passes the shim binary to the efi firmware,
in addition to the kernel binary.

x86 has this for a while already, this brings arm on par.

docs update with some background below.

take care,
  Gerd

--- a/docs/system/linuxboot.rst
+++ b/docs/system/linuxboot.rst
@@ -17,6 +17,15 @@ Use ``-kernel`` to provide the Linux kernel image and ``-append`` to
 give the kernel command line arguments. The ``-initrd`` option can be
 used to provide an INITRD image.
 
+The ``-shim`` option specifies the shim.efi binary.  This is needed
+when using direct kernel boot with UEFI secure boot enabled.  The
+verification chain used by linux distros requires shim.efi.  Typically
+shim.efi is signed by micsosoft and verified by the firmware.  The
+linux kernel is signed by the distro and is verified by shim.efi.  So
+without shim.efi in the loop secure boot verification will not work.
+Usually you can find shim.efi as ``EFI/BOOT/BOOT{X64,AA64}.EFI`` on
+distro install media.
+
 If you do not need graphical output, you can disable it and redirect the
 virtual serial port and the QEMU monitor to the console with the
 ``-nographic`` option. The typical command line is:

On Thu, 4 Jun 2026 at 10:27, Gerd Hoffmann <kraxel@redhat.com> wrote:
>
> On Thu, May 28, 2026 at 03:28:05PM +0100, Peter Maydell wrote:
> > On Thu, 21 May 2026 at 12:28, Gerd Hoffmann <kraxel@redhat.com> wrote:
> > >
> > > Also little refactoring in preparation
> > > to avoid code duplication.
> > >
> > > Gerd Hoffmann (3):
> > >   hw/nvram: add load_image_to_fw_cfg_file()
> > >   hw/i386: switch shim loading to load_image_to_fw_cfg_file
> > >   hw/arm: add support for shim loading
> >
> > Any chance of some information on what this is?
>
> It passes the shim binary to the efi firmware,
> in addition to the kernel binary.
>
> x86 has this for a while already, this brings arm on par.
>
> docs update with some background below.
>
> take care,
>   Gerd
>
> --- a/docs/system/linuxboot.rst
> +++ b/docs/system/linuxboot.rst
> @@ -17,6 +17,15 @@ Use ``-kernel`` to provide the Linux kernel image and ``-append`` to
>  give the kernel command line arguments. The ``-initrd`` option can be
>  used to provide an INITRD image.
>
> +The ``-shim`` option specifies the shim.efi binary.  This is needed
> +when using direct kernel boot with UEFI secure boot enabled.  The
> +verification chain used by linux distros requires shim.efi.  Typically
> +shim.efi is signed by micsosoft and verified by the firmware.  The
> +linux kernel is signed by the distro and is verified by shim.efi.  So
> +without shim.efi in the loop secure boot verification will not work.
> +Usually you can find shim.efi as ``EFI/BOOT/BOOT{X64,AA64}.EFI`` on
> +distro install media.

Thanks. I'm not sure why you'd want to enable UEFI secure boot
when you're not booting via UEFI, though.

Do we actually run the shim.efi code, or is it just there to
be "verified" ?

-- PMM

On Mon, Jun 08, 2026 at 10:24:28AM +0100, Peter Maydell wrote:
> On Thu, 4 Jun 2026 at 10:27, Gerd Hoffmann <kraxel@redhat.com> wrote:
> >
> > On Thu, May 28, 2026 at 03:28:05PM +0100, Peter Maydell wrote:
> > > On Thu, 21 May 2026 at 12:28, Gerd Hoffmann <kraxel@redhat.com> wrote:
> > > >
> > > > Also little refactoring in preparation
> > > > to avoid code duplication.
> > > >
> > > > Gerd Hoffmann (3):
> > > >   hw/nvram: add load_image_to_fw_cfg_file()
> > > >   hw/i386: switch shim loading to load_image_to_fw_cfg_file
> > > >   hw/arm: add support for shim loading
> > >
> > > Any chance of some information on what this is?
> >
> > It passes the shim binary to the efi firmware,
> > in addition to the kernel binary.
> >
> > x86 has this for a while already, this brings arm on par.
> >
> > docs update with some background below.
> >
> > take care,
> >   Gerd
> >
> > --- a/docs/system/linuxboot.rst
> > +++ b/docs/system/linuxboot.rst
> > @@ -17,6 +17,15 @@ Use ``-kernel`` to provide the Linux kernel image and ``-append`` to
> >  give the kernel command line arguments. The ``-initrd`` option can be
> >  used to provide an INITRD image.
> >
> > +The ``-shim`` option specifies the shim.efi binary.  This is needed
> > +when using direct kernel boot with UEFI secure boot enabled.  The
> > +verification chain used by linux distros requires shim.efi.  Typically
> > +shim.efi is signed by micsosoft and verified by the firmware.  The
> > +linux kernel is signed by the distro and is verified by shim.efi.  So
> > +without shim.efi in the loop secure boot verification will not work.
> > +Usually you can find shim.efi as ``EFI/BOOT/BOOT{X64,AA64}.EFI`` on
> > +distro install media.
> 
> Thanks. I'm not sure why you'd want to enable UEFI secure boot
> when you're not booting via UEFI, though.

When not booting via UEFI you can ignore that.

> Do we actually run the shim.efi code, or is it just there to
> be "verified" ?

edk2 firmware will load + run it (if present).

take care,
  Gerd

On Mon, 8 Jun 2026 at 14:03, Gerd Hoffmann <kraxel@redhat.com> wrote:
>
> On Mon, Jun 08, 2026 at 10:24:28AM +0100, Peter Maydell wrote:
> > On Thu, 4 Jun 2026 at 10:27, Gerd Hoffmann <kraxel@redhat.com> wrote:
> > >
> > > On Thu, May 28, 2026 at 03:28:05PM +0100, Peter Maydell wrote:
> > > > On Thu, 21 May 2026 at 12:28, Gerd Hoffmann <kraxel@redhat.com> wrote:
> > > > >
> > > > > Also little refactoring in preparation
> > > > > to avoid code duplication.
> > > > >
> > > > > Gerd Hoffmann (3):
> > > > >   hw/nvram: add load_image_to_fw_cfg_file()
> > > > >   hw/i386: switch shim loading to load_image_to_fw_cfg_file
> > > > >   hw/arm: add support for shim loading
> > > >
> > > > Any chance of some information on what this is?
> > >
> > > It passes the shim binary to the efi firmware,
> > > in addition to the kernel binary.
> > >
> > > x86 has this for a while already, this brings arm on par.
> > >
> > > docs update with some background below.
> > >
> > > take care,
> > >   Gerd
> > >
> > > --- a/docs/system/linuxboot.rst
> > > +++ b/docs/system/linuxboot.rst
> > > @@ -17,6 +17,15 @@ Use ``-kernel`` to provide the Linux kernel image and ``-append`` to
> > >  give the kernel command line arguments. The ``-initrd`` option can be
> > >  used to provide an INITRD image.
> > >
> > > +The ``-shim`` option specifies the shim.efi binary.  This is needed
> > > +when using direct kernel boot with UEFI secure boot enabled.  The
> > > +verification chain used by linux distros requires shim.efi.  Typically
> > > +shim.efi is signed by micsosoft and verified by the firmware.  The
> > > +linux kernel is signed by the distro and is verified by shim.efi.  So
> > > +without shim.efi in the loop secure boot verification will not work.
> > > +Usually you can find shim.efi as ``EFI/BOOT/BOOT{X64,AA64}.EFI`` on
> > > +distro install media.
> >
> > Thanks. I'm not sure why you'd want to enable UEFI secure boot
> > when you're not booting via UEFI, though.
>
> When not booting via UEFI you can ignore that.

But if I'm doing direct kernel boot then by definition I'm
not booting via UEFI, I'm directly booting the kernel...

thanks
-- PMM

  Hi,

> > When not booting via UEFI you can ignore that.
> 
> But if I'm doing direct kernel boot then by definition I'm
> not booting via UEFI, I'm directly booting the kernel...

You can (on aarch64) do direct kernel boot both with and without
UEFI firmware ...

Without firmware qemu will load the kernel binary, then start the VM
with the instruction pointer register pointing to the elf entry point.

With firmware qemu exposes kernel + initrd (and with this patch shim
too) via fw_cfg, and the firmware can pick it up from there and run
it (instead of trying to boot via disk / cdrom / network).

take care,
  Gerd

On Mon, 8 Jun 2026 at 14:23, Gerd Hoffmann <kraxel@redhat.com> wrote:
>
>   Hi,
>
> > > When not booting via UEFI you can ignore that.
> >
> > But if I'm doing direct kernel boot then by definition I'm
> > not booting via UEFI, I'm directly booting the kernel...
>
> You can (on aarch64) do direct kernel boot both with and without
> UEFI firmware ...
>
> Without firmware qemu will load the kernel binary, then start the VM
> with the instruction pointer register pointing to the elf entry point.
>
> With firmware qemu exposes kernel + initrd (and with this patch shim
> too) via fw_cfg, and the firmware can pick it up from there and run
> it (instead of trying to boot via disk / cdrom / network).

I don't really think of the latter as being direct-boot, and
nor does our documentation:

https://www.qemu.org/docs/master/system/invocation.html#hxtool-8

# There are broadly 4 ways you can boot a system with QEMU.
#
#  - specify a firmware and let it control finding a kernel
#  - specify a firmware and pass a hint to the kernel to boot
#  - direct kernel image boot
#  - manually load files into the guest's address space
#
# The third method is useful for quickly testing kernels but as there is
# no firmware to pass configuration information to the kernel [...]

Anyway, I'll reply to your patch updating the documentation
with some suggestions for expanding it.

-- PMM

  Hi,

> > With firmware qemu exposes kernel + initrd (and with this patch shim
> > too) via fw_cfg, and the firmware can pick it up from there and run
> > it (instead of trying to boot via disk / cdrom / network).
> 
> I don't really think of the latter as being direct-boot, and
> nor does our documentation:

> #  - specify a firmware and pass a hint to the kernel to boot
> #  - direct kernel image boot

That is a technical detail which doesn't make much of a difference
from the end user perspective.  And often people talk about "direct
kernel boot" without drawing a line between these two cases, because the
user-visible behavior is pretty much identical:  You pass a kernel to
qemu via '-kernel', and it gets booted ...

take care,
  Gerd

On Tue, 9 Jun 2026 at 11:10, Gerd Hoffmann <kraxel@redhat.com> wrote:
>
>   Hi,
>
> > > With firmware qemu exposes kernel + initrd (and with this patch shim
> > > too) via fw_cfg, and the firmware can pick it up from there and run
> > > it (instead of trying to boot via disk / cdrom / network).
> >
> > I don't really think of the latter as being direct-boot, and
> > nor does our documentation:
>
> > #  - specify a firmware and pass a hint to the kernel to boot
> > #  - direct kernel image boot
>
> That is a technical detail which doesn't make much of a difference
> from the end user perspective.  And often people talk about "direct
> kernel boot" without drawing a line between these two cases, because the
> user-visible behavior is pretty much identical:  You pass a kernel to
> qemu via '-kernel', and it gets booted ...

As an end user I find them majorly different -- I usually
don't want the firmware, because it takes forever to boot
if you do that.

This is probably partly an x86 vs Arm difference: for x86 there
is always some kind of BIOS booted, but for Arm there
by default is not, and direct kernel boot is much more
common.

thanks
-- PMM

  Hi,

> > > #  - specify a firmware and pass a hint to the kernel to boot
> > > #  - direct kernel image boot
> >
> > That is a technical detail which doesn't make much of a difference
> > from the end user perspective.  And often people talk about "direct
> > kernel boot" without drawing a line between these two cases, because the
> > user-visible behavior is pretty much identical:  You pass a kernel to
> > qemu via '-kernel', and it gets booted ...
> 
> As an end user I find them majorly different -- I usually
> don't want the firmware, because it takes forever to boot
> if you do that.

Not sure what exactly you are doing, but for me edk2 is done in less
than a second (unless I turn on firmware debug logging), and that on
a rpi4 host which isn't exactly fast hardware.  I wouldn't call that
"forever".

> This is probably partly an x86 vs Arm difference: for x86 there
> is always some kind of BIOS booted, but for Arm there
> by default is not, and direct kernel boot is much more
> common.

Yes, on x86 you need something (be it ovmf or seabios or qboot) which
places smbios and acpi tables properly in guest memory.  On arm the
linux kernel is happy with the device tree, so it is possible to skip
the firmware part (unless you want run the guest in acpi=on mode).

take care,
  Gerd

On Tue, 9 Jun 2026 at 13:00, Gerd Hoffmann <kraxel@redhat.com> wrote:
>
>   Hi,
>
> > > > #  - specify a firmware and pass a hint to the kernel to boot
> > > > #  - direct kernel image boot
> > >
> > > That is a technical detail which doesn't make much of a difference
> > > from the end user perspective.  And often people talk about "direct
> > > kernel boot" without drawing a line between these two cases, because the
> > > user-visible behavior is pretty much identical:  You pass a kernel to
> > > qemu via '-kernel', and it gets booted ...
> >
> > As an end user I find them majorly different -- I usually
> > don't want the firmware, because it takes forever to boot
> > if you do that.
>
> Not sure what exactly you are doing, but for me edk2 is done in less
> than a second (unless I turn on firmware debug logging), and that on
> a rpi4 host which isn't exactly fast hardware.  I wouldn't call that
> "forever".

If you're running TCG emulation then booting EDK2 is definitely not
that fast, and I think a lot of use of QEMU for aarch64 targets is TCG,
not KVM.

thanks
-- PMM

On Tue, Jun 09, 2026 at 01:44:25PM +0100, Peter Maydell wrote:
> On Tue, 9 Jun 2026 at 13:00, Gerd Hoffmann <kraxel@redhat.com> wrote:
> >
> >   Hi,
> >
> > > > > #  - specify a firmware and pass a hint to the kernel to boot
> > > > > #  - direct kernel image boot
> > > >
> > > > That is a technical detail which doesn't make much of a difference
> > > > from the end user perspective.  And often people talk about "direct
> > > > kernel boot" without drawing a line between these two cases, because the
> > > > user-visible behavior is pretty much identical:  You pass a kernel to
> > > > qemu via '-kernel', and it gets booted ...
> > >
> > > As an end user I find them majorly different -- I usually
> > > don't want the firmware, because it takes forever to boot
> > > if you do that.
> >
> > Not sure what exactly you are doing, but for me edk2 is done in less
> > than a second (unless I turn on firmware debug logging), and that on
> > a rpi4 host which isn't exactly fast hardware.  I wouldn't call that
> > "forever".
> 
> If you're running TCG emulation then booting EDK2 is definitely not
> that fast, and I think a lot of use of QEMU for aarch64 targets is TCG,
> not KVM.

On my x86 workstation edk2 boot time on tcg is not very different from
the rpi4 with kvm, also less than one second (until it complains that
the kernel isn't arm ;).

The rpi4 with tcg takes quite some time indeed, but edk2 isn't
exceptionally slow.  Booting until the kernel panics because there is no
root filesystem takes ~30 seconds, and those are roughly 50% / 50%
splitted between firmware and kernel.  A good chunk of the firmware time
is probably the zboot efi stub for kernel self-decompression (would have
to instrument the firmware for more details on that).

Comparing that to direct boot without firmware does not work for me:

  unable to handle EFI zboot image with "zstd" compression
  qemu-system-aarch64: could not load kernel '/boot/vmlinuz-7.0.11-200.fc44.aarch64'

Anyway, I'll go over the comments and try to make the docs patch more
clear for people with less UEFI background.  Update should come later
this week.

take care,
  Gerd

On Tue, 9 Jun 2026 at 14:42, Gerd Hoffmann <kraxel@redhat.com> wrote:
> The rpi4 with tcg takes quite some time indeed, but edk2 isn't
> exceptionally slow.  Booting until the kernel panics because there is no
> root filesystem takes ~30 seconds, and those are roughly 50% / 50%
> splitted between firmware and kernel.

Put another way, booting via EDK2 is doubling the time taken :-)

> A good chunk of the firmware time
> is probably the zboot efi stub for kernel self-decompression (would have
> to instrument the firmware for more details on that).
>
> Comparing that to direct boot without firmware does not work for me:
>
>   unable to handle EFI zboot image with "zstd" compression
>   qemu-system-aarch64: could not load kernel '/boot/vmlinuz-7.0.11-200.fc44.aarch64'

That error happens if you didn't have libzstd-dev available when you
built QEMU. A QEMU with zstd support should be able to decompress
a zstd EFI image.

thanks
-- PMM