From nobody Sat Nov 1 07:39:38 2025 Delivered-To: importer@patchew.org Received-SPF: pass (zoho.com: domain of gnu.org designates 208.118.235.17 as permitted sender) client-ip=208.118.235.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Authentication-Results: mx.zohomail.com; spf=pass (zoho.com: domain of gnu.org designates 208.118.235.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=fail(p=none dis=none) header.from=redhat.com Return-Path: Received: from lists.gnu.org (lists.gnu.org [208.118.235.17]) by mx.zohomail.com with SMTPS id 1527071084871347.6143512691631; Wed, 23 May 2018 03:24:44 -0700 (PDT) Received: from localhost ([::1]:60207 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fLQwl-0006cL-Qh for importer@patchew.org; Wed, 23 May 2018 06:24:43 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33520) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fLQvP-0006GN-CE for qemu-devel@nongnu.org; Wed, 23 May 2018 06:23:20 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fLQvK-00026W-Am for qemu-devel@nongnu.org; Wed, 23 May 2018 06:23:19 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:59474 helo=mx1.redhat.com) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1fLQvK-00026A-53 for qemu-devel@nongnu.org; Wed, 23 May 2018 06:23:14 -0400 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 38A5840704B0; Wed, 23 May 2018 10:23:13 +0000 (UTC) Received: from dell-r430-03.lab.eng.brq.redhat.com (dell-r430-03.lab.eng.brq.redhat.com [10.37.153.18]) by smtp.corp.redhat.com (Postfix) with ESMTP id 724282156A31; Wed, 23 May 2018 10:23:12 +0000 (UTC) From: Igor Mammedov To: qemu-devel@nongnu.org Date: Wed, 23 May 2018 12:22:30 +0200 Message-Id: <1527070950-208350-1-git-send-email-imammedo@redhat.com> X-Scanned-By: MIMEDefang 2.78 on 10.11.54.6 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.7]); Wed, 23 May 2018 10:23:13 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.7]); Wed, 23 May 2018 10:23:13 +0000 (UTC) for IP:'10.11.54.6' DOMAIN:'int-mx06.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'imammedo@redhat.com' RCPT:'' X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 66.187.233.73 Subject: [Qemu-devel] [PATCH] arm: fix qemu crash on startup with -bios option X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Auger Eric , Andrew Jones , Peter Maydell Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" X-ZohoMail: RSF_0 Z_629925259 SPT_0 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" When QEMU is started with following CLI -machine virt,gic-version=3D3,accel=3Dkvm -cpu host -bios AAVMF_CODE.fd it crashes with abort at accel/kvm/kvm-all.c:2164: KVM_SET_DEVICE_ATTR failed: Group 6 attr 0x000000000000c665: Invalid argum= ent Which is caused by implicit dependecy of kvm_arm_gicv3_reset() on arm_gicv3_icc_reset() where the later is called by CPU reset reset callback. However commit: 3b77f6c arm/boot: split load_dtb() from arm_load_kernel() broke CPU reset callback registration in case arm_load_kernel() ... if (!info->kernel_filename || info->firmware_loaded) branch is taken, i.e. it's sufficient to provide a firmware or do not provide kernel on CLI to skip cpu reset callback registration, where before offending commit the callback has been registered unconditionally. Fix it by registering the callback right at the begging of arm_load_kernel() unconditionally instead of doing it at the end. NOTE: we probably should eleminate that dependency anyways as well as separate arch CPU reset parts from arm_load_kernel() into CPU itself, but that refactoring that I probably would have to do anyways later for CPU hotplug to work. Reported-by: Auger Eric Signed-off-by: Igor Mammedov Reviewed-by: Eric Auger Tested-by: Eric Auger --- Thanks Andrew Jones for host with reproducer. --- hw/arm/boot.c | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/hw/arm/boot.c b/hw/arm/boot.c index 9496f33..1e48166 100644 --- a/hw/arm/boot.c +++ b/hw/arm/boot.c @@ -926,6 +926,15 @@ void arm_load_kernel(ARMCPU *cpu, struct arm_boot_info= *info) static const ARMInsnFixup *primary_loader; AddressSpace *as =3D arm_boot_address_space(cpu, info); =20 + /* CPU objects (unlike devices) are not automatically reset on system + * reset, so we must always register a handler to do so. If we're + * actually loading a kernel, the handler is also responsible for + * arranging that we start it correctly. + */ + for (cs =3D first_cpu; cs; cs =3D CPU_NEXT(cs)) { + qemu_register_reset(do_cpu_reset, ARM_CPU(cs)); + } + /* The board code is not supposed to set secure_board_setup unless * running its code in secure mode is actually possible, and KVM * doesn't support secure. @@ -1143,15 +1152,6 @@ void arm_load_kernel(ARMCPU *cpu, struct arm_boot_in= fo *info) ARM_CPU(cs)->env.boot_info =3D info; } =20 - /* CPU objects (unlike devices) are not automatically reset on system - * reset, so we must always register a handler to do so. If we're - * actually loading a kernel, the handler is also responsible for - * arranging that we start it correctly. - */ - for (cs =3D first_cpu; cs; cs =3D CPU_NEXT(cs)) { - qemu_register_reset(do_cpu_reset, ARM_CPU(cs)); - } - if (!info->skip_dtb_autoload && have_dtb(info)) { if (arm_load_dtb(info->dtb_start, info, info->dtb_limit, as) < 0) { exit(1); --=20 1.8.3.1