From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50705) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W5SaD-0002VN-Ij for qemu-devel@nongnu.org; Mon, 20 Jan 2014 23:05:07 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W5Sa7-0006Nn-Ec for qemu-devel@nongnu.org; Mon, 20 Jan 2014 23:05:01 -0500 Received: from mail-pb0-f51.google.com ([209.85.160.51]:42959) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W5Sa7-0006Nd-8B for qemu-devel@nongnu.org; Mon, 20 Jan 2014 23:04:55 -0500 Received: by mail-pb0-f51.google.com with SMTP id un15so4155952pbc.38 for ; Mon, 20 Jan 2014 20:04:53 -0800 (PST) Message-ID: <52DDF1DD.2060405@ozlabs.ru> Date: Tue, 21 Jan 2014 15:04:45 +1100 From: Alexey Kardashevskiy MIME-Version: 1.0 References: <1389069353-13467-1-git-send-email-aik@ozlabs.ru> In-Reply-To: Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit 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: Alexander Graf Cc: Paolo Bonzini , qemu-ppc , QEMU Developers , Anthony Liguori On 01/21/2014 02:11 AM, Alexander Graf wrote: > > 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. >> >> Signed-off-by: Alexey Kardashevskiy > > How about we just remove non-ELF loading from -kernel on -M pseries? We are fine with that, never tried non-elf anyway, I'll cook another patch for that. I suppose I do exit(), just one level up, in spapr_machine:init(), correct? > > > Alex > >> --- >> >> >> 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. >> >> The patch fixes the issue but there are still questions. >> >> 1. Do we need more sophisticated error checking here? Return -2 instead of exit(1) >> and do exit(1) few levels up? >> >> 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? >> >> >> --- >> include/hw/elf_ops.h | 13 +++++++++---- >> 1 file changed, 9 insertions(+), 4 deletions(-) >> >> 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 != ehdr.e_machine) >> if (EM_PPC != ehdr.e_machine) >> - goto fail; >> + goto arch_fail; >> break; >> case EM_X86_64: >> if (EM_X86_64 != ehdr.e_machine) >> if (EM_386 != ehdr.e_machine) >> - goto fail; >> + goto arch_fail; >> break; >> case EM_MICROBLAZE: >> if (EM_MICROBLAZE != ehdr.e_machine) >> if (EM_MICROBLAZE_OLD != ehdr.e_machine) >> - goto fail; >> + goto arch_fail; >> break; >> default: >> if (elf_machine != ehdr.e_machine) >> - goto fail; >> + goto arch_fail; >> } >> >> 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); >> } >> -- >> 1.8.4.rc4 >> > -- Alexey