qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
* [Qemu-devel] Should qemu -kernel option be able to gunzip kernel? (aarch64)
@ 2014-07-29 19:49 Richard W.M. Jones
  2014-07-29 20:31 ` Peter Maydell
  0 siblings, 1 reply; 2+ messages in thread
From: Richard W.M. Jones @ 2014-07-29 19:49 UTC (permalink / raw)
  To: qemu-devel

On Fedora/aarch64, the kernel in /boot is a gzip-compressed file:

$ file /boot/vmlinuz-*
/boot/vmlinuz-0-rescue-520be7dc677d4fab99d3d3ce91f90c84: gzip compressed data, max compression, from Unix
/boot/vmlinuz-3.16.0-0.rc6.git3.1.rwmj2.fc22.aarch64:    gzip compressed data, max compression, from Unix
/boot/vmlinuz-3.16.0-0.rc6.git3.1.rwmj3.fc22.aarch64:    gzip compressed data, max compression, from Unix
/boot/vmlinuz-3.16.0-0.rc6.git3.1.rwmj4.fc22.aarch64:    gzip compressed data, max compression, from Unix

[not just for the custom kernels I've been building ...]

Apparently UEFI and u-boot can just handle this by uncompressing the
kernel on the fly.

However qemu-system-aarch64 -kernel option definitely can*not*, with
the result that if you do the "obvious":

  qemu-system-aarch64 -kernel /boot/vmlinuz-xxx

it just hangs immediately, because it's trying to execute gzip data.

I don't know the rights and wrongs of this.  Maybe Fedora is wrong for
having a gzip-compressed kernel.  But should the -kernel option be
able to detect if the file is gzip encoded and uncompress it on the
fly?  (If so I'll post a patch for this unless someone else jumps in).

Mainly I'm asking because I've no idea what is the right thing to do
here.  There could be another obvious fix.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [Qemu-devel] Should qemu -kernel option be able to gunzip kernel? (aarch64)
  2014-07-29 19:49 [Qemu-devel] Should qemu -kernel option be able to gunzip kernel? (aarch64) Richard W.M. Jones
@ 2014-07-29 20:31 ` Peter Maydell
  0 siblings, 0 replies; 2+ messages in thread
From: Peter Maydell @ 2014-07-29 20:31 UTC (permalink / raw)
  To: Richard W.M. Jones; +Cc: QEMU Developers

On 29 July 2014 20:49, Richard W.M. Jones <rjones@redhat.com> wrote:
> On Fedora/aarch64, the kernel in /boot is a gzip-compressed file

> Apparently UEFI and u-boot can just handle this by uncompressing the
> kernel on the fly.
>
> However qemu-system-aarch64 -kernel option definitely can*not*, with
> the result that if you do the "obvious":
>
>   qemu-system-aarch64 -kernel /boot/vmlinuz-xxx
>
> it just hangs immediately, because it's trying to execute gzip data.
>
> I don't know the rights and wrongs of this.  Maybe Fedora is wrong for
> having a gzip-compressed kernel.  But should the -kernel option be
> able to detect if the file is gzip encoded and uncompress it on the
> fly?  (If so I'll post a patch for this unless someone else jumps in).
>
> Mainly I'm asking because I've no idea what is the right thing to do
> here.  There could be another obvious fix.

Yeah, the AArch64 approach to compressed kernels is "the
bootloader should do it" (unlike the 32 bit ARM approach
where the kernel has a decompressor tacked on the front
of it). So I agree that we should be a good bootloader and
do the decompression, assuming it's not a total pain to do so
only for AArch64 kernels.

thanks
-- PMM

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2014-07-29 20:31 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-07-29 19:49 [Qemu-devel] Should qemu -kernel option be able to gunzip kernel? (aarch64) Richard W.M. Jones
2014-07-29 20:31 ` Peter Maydell

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).