From: Laszlo Ersek <lersek@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: Andrew Jones <drjones@redhat.com>,
QEMU Developers <qemu-devel@nongnu.org>"Richard W.M. Jones"
<rjones@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v3 6/7] hw/arm: pass pristine kernel image to guest firmware over fw_cfg
Date: Fri, 12 Dec 2014 15:10:42 +0100 [thread overview]
Message-ID: <548AF762.4020707@redhat.com> (raw)
In-Reply-To: <CAFEAcA9JiL-JpQ85OFOwb2XxHFm5La-P9kyDf0NYbLS53HFFig@mail.gmail.com>
On 12/12/14 14:57, Peter Maydell wrote:
> On 12 December 2014 at 13:52, Laszlo Ersek <lersek@redhat.com> wrote:
>> On 12/12/14 14:20, Peter Maydell wrote:
>>> If we have a real bootloader in the UEFI firmware, why do we need
>>> to do decompression for it? We only do this in the builtin bootloader
>>> because QEMU is acting as the bootloader and has to support the
>>> feature itself. I would have thought that the UEFI builtin kernel
>>> booting support already supported decompressing the kernel...
>>
>> The "UEFI builtin kernel booting support" will qualify as "builtin" only
>> after my 2500 line patch series is merged in edk2.
>
> I had in mind the support for UEFI loading kernels off
> hard disks, which presumably is already present.
Ah, I see.
Sure, if you have a kernel image (with the EFI stub) that is an
*immediately executable* EFI binary, then you can just go to the UEFI
shell, navigate to the filesystem / directory that hosts that image, and
run it. (Similarly, PXE boot it etc.)
But in this case the EFI binary is compressed with gzip (for aarch64
kernels); you couldn't even run it from the UEFI shell.
Or else, if you thought of grub2 loading a kernel from the disk with
UEFI protocols -- that works too, but then it's grub that does the
decompression.
(There's a plethora of ways to boot UEFI kernels, and I've recently
asked Matt Fleming if he could write up a comprehensive blog post or
similar about all of them. Hopefully the community will be able to refer
to an authoritative summary sometime next year.)
>
>> Zlib decompression is not present in edk2 (it only has a TianoCore
>> variant of LZMA), and I didn't want to impede (in the community sense)
>> my edk2 patchset even more (ie. beyond its current size) by importing
>> libz too.
>
> Fair enough. This avoids odd inconsistency in compressed kernel
> support between the f/w and non f/w setups, anyway.
>
> If you fix the stray space then
> Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
>
> thanks
> -- PMM
>
Awesome!
Thanks
Laszlo
next prev parent reply other threads:[~2014-12-12 14:10 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-09 1:12 [Qemu-devel] [PATCH v3 0/7] fw_cfg, bootorder, and UEFI+'-kernel' on arm/virt Laszlo Ersek
2014-12-09 1:12 ` [Qemu-devel] [PATCH v3 1/7] fw_cfg: max access size and region size are the same for MMIO data reg Laszlo Ersek
2014-12-09 1:13 ` [Qemu-devel] [PATCH v3 2/7] fw_cfg: introduce the "data_memwidth" property Laszlo Ersek
2014-12-12 12:49 ` Peter Maydell
2014-12-12 13:39 ` Laszlo Ersek
2014-12-12 13:41 ` Peter Maydell
2014-12-09 1:13 ` [Qemu-devel] [PATCH v3 3/7] fw_cfg: expose the "data_memwidth" prop with fw_cfg_init_data_memwidth() Laszlo Ersek
2014-12-09 1:13 ` [Qemu-devel] [PATCH v3 4/7] arm: add fw_cfg to "virt" board Laszlo Ersek
2014-12-12 12:55 ` Peter Maydell
2014-12-12 13:41 ` Laszlo Ersek
2014-12-09 1:13 ` [Qemu-devel] [PATCH v3 5/7] hw/loader: split out load_image_gzipped_buffer() Laszlo Ersek
2014-12-12 13:11 ` Peter Maydell
2014-12-12 13:43 ` Laszlo Ersek
2014-12-09 1:13 ` [Qemu-devel] [PATCH v3 6/7] hw/arm: pass pristine kernel image to guest firmware over fw_cfg Laszlo Ersek
2014-12-12 13:20 ` Peter Maydell
2014-12-12 13:52 ` Laszlo Ersek
2014-12-12 13:57 ` Peter Maydell
2014-12-12 14:10 ` Laszlo Ersek [this message]
2014-12-12 14:14 ` Richard W.M. Jones
2014-12-12 14:24 ` Laszlo Ersek
2014-12-09 1:13 ` [Qemu-devel] [PATCH v3 7/7] hw/arm/virt: enable passing of EFI-stubbed kernel to guest UEFI firmware Laszlo Ersek
2014-12-12 13:20 ` Peter Maydell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=548AF762.4020707@redhat.com \
--to=lersek@redhat.com \
--cc=drjones@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.