From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60350) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XzQvm-0003ZO-3k for qemu-devel@nongnu.org; Fri, 12 Dec 2014 09:10:59 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XzQvh-0006Cr-6A for qemu-devel@nongnu.org; Fri, 12 Dec 2014 09:10:53 -0500 Received: from mx1.redhat.com ([209.132.183.28]:56765) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XzQvg-0006Ch-Pc for qemu-devel@nongnu.org; Fri, 12 Dec 2014 09:10:49 -0500 Message-ID: <548AF762.4020707@redhat.com> Date: Fri, 12 Dec 2014 15:10:42 +0100 From: Laszlo Ersek MIME-Version: 1.0 References: <1418087585-27601-1-git-send-email-lersek@redhat.com> <1418087585-27601-7-git-send-email-lersek@redhat.com> <548AF32B.2020503@redhat.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v3 6/7] hw/arm: pass pristine kernel image to guest firmware over fw_cfg List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Andrew Jones , QEMU Developers "Richard W.M. Jones" On 12/12/14 14:57, Peter Maydell wrote: > On 12 December 2014 at 13:52, Laszlo Ersek 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 > > thanks > -- PMM > Awesome! Thanks Laszlo