From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35884) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W5GVn-00079W-QO for qemu-devel@nongnu.org; Mon, 20 Jan 2014 10:11:46 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W5GVh-0006WB-Kp for qemu-devel@nongnu.org; Mon, 20 Jan 2014 10:11:39 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Alexander Graf In-Reply-To: <1389069353-13467-1-git-send-email-aik@ozlabs.ru> Date: Mon, 20 Jan 2014 16:11:29 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1389069353-13467-1-git-send-email-aik@ozlabs.ru> Subject: Re: [Qemu-devel] [RFC PATCH] elf loader: exit if incompatible architecture is detected List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexey Kardashevskiy Cc: Paolo Bonzini , qemu-ppc , QEMU Developers , Anthony Liguori On 07.01.2014, at 05:35, Alexey Kardashevskiy wrote: > If we know for sure that the image in "-kernel" is an ELF and we know = its > architecture and it is not supported by the current QEMU, there is no > point to continue trying booting this image so let's exit once we = deteced > this fact. >=20 > Signed-off-by: Alexey Kardashevskiy How about we just remove non-ELF loading from -kernel on -M pseries? Alex > --- >=20 >=20 > One of our users tried an X86 image with qemu-system-ppc64. Instead of > printing some reasonable message (which is possible in this case as = the image > is ELF), QEMU (spapr.c) simply copied the image in RAM as a raw image = and > SLOF failed to boot from it. >=20 > The patch fixes the issue but there are still questions. >=20 > 1. Do we need more sophisticated error checking here? Return -2 = instead of exit(1) > and do exit(1) few levels up? >=20 > 2. The patch does not handle x86's vmlinuz case - these images are not = ELFs > but "Linux kernel x86 boot executable bzImage" and QEMU does not parse = them. > As a result, SLOF crashes with the registers dump. Do we really care = to handle this? >=20 >=20 > --- > include/hw/elf_ops.h | 13 +++++++++---- > 1 file changed, 9 insertions(+), 4 deletions(-) >=20 > diff --git a/include/hw/elf_ops.h b/include/hw/elf_ops.h > index acc701e..6bcc61f 100644 > --- a/include/hw/elf_ops.h > +++ b/include/hw/elf_ops.h > @@ -212,21 +212,21 @@ static int glue(load_elf, SZ)(const char *name, = int fd, > case EM_PPC64: > if (EM_PPC64 !=3D ehdr.e_machine) > if (EM_PPC !=3D ehdr.e_machine) > - goto fail; > + goto arch_fail; > break; > case EM_X86_64: > if (EM_X86_64 !=3D ehdr.e_machine) > if (EM_386 !=3D ehdr.e_machine) > - goto fail; > + goto arch_fail; > break; > case EM_MICROBLAZE: > if (EM_MICROBLAZE !=3D ehdr.e_machine) > if (EM_MICROBLAZE_OLD !=3D ehdr.e_machine) > - goto fail; > + goto arch_fail; > break; > default: > if (elf_machine !=3D ehdr.e_machine) > - goto fail; > + goto arch_fail; > } >=20 > if (pentry) > @@ -306,4 +306,9 @@ static int glue(load_elf, SZ)(const char *name, = int fd, > g_free(data); > g_free(phdr); > return -1; > + > +arch_fail: > + fprintf(stderr, "qemu: could not load arch-incompatible kernel = '%s'\n", > + name); > + exit(1); > } > --=20 > 1.8.4.rc4 >=20