From nobody Thu Apr 18 17:35:54 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) client-ip=209.51.188.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Authentication-Results: mx.zohomail.com; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org ARC-Seal: i=1; a=rsa-sha256; t=1578930517; cv=none; d=zohomail.com; s=zohoarc; b=O/qoCpnYuwKOdzujy1qQpnWQtWYcanwLGkV6N+vpjpR7DnagLSfKFgioohAQoQtmr4S7HCEJXltALqK39B9cKynE+wCmve/LWQtem1LsJoLi/PcSx4yqzPW5GYMCEKe1g/rupiLQMzBNxhDdonTOcsGLKXr65e/QcZ8myqz/AFY= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1578930517; h=Content-Type:Cc:Date:From:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:Sender:Subject:To; bh=UvV51rWqqElFPDA6dsEY2dah0Ws/5wZ1besb3EOGmoo=; b=jK3DjSAkBwC9+cUvE9avTmfS4dRTLI4sFX1ZfQxOUlnm9qXhRLMt8vSj64UuLNtQxf8qAwBTnMM32TteriIuE5c5YlyffdedEHlxWEDS4ZsW6ksc1t18LyDBqjSopTq7Tv8cXq1a8sgX37lgyHKzMXArHNVt/3I3NSmFalvmpaA= ARC-Authentication-Results: i=1; mx.zohomail.com; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org Return-Path: Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) by mx.zohomail.com with SMTPS id 1578930517295529.9868351810808; Mon, 13 Jan 2020 07:48:37 -0800 (PST) Received: from localhost ([::1]:52058 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ir1xE-0002g0-5J for importer@patchew.org; Mon, 13 Jan 2020 10:48:36 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:36071) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ir1v2-0001Az-QK for qemu-devel@nongnu.org; Mon, 13 Jan 2020 10:46:21 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ir1v1-0001jl-Os for qemu-devel@nongnu.org; Mon, 13 Jan 2020 10:46:20 -0500 Received: from mail.dornerworks.com ([12.207.209.150]:20480 helo=webmail.dornerworks.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ir1uz-0001ZO-Fx; Mon, 13 Jan 2020 10:46:17 -0500 From: Jeff Kubascik To: Peter Maydell , , Subject: [PATCH] arm/gicv3: update virtual irq state after IAR register read Date: Mon, 13 Jan 2020 10:46:07 -0500 Message-ID: <20200113154607.97032-1-jeff.kubascik@dornerworks.com> X-Mailer: git-send-email 2.17.1 MIME-Version: 1.0 X-Originating-IP: [172.27.13.179] X-ClientProxiedBy: Mcbain.dw.local (172.27.1.45) To Mcbain.dw.local (172.27.1.45) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 12.207.209.150 X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Stewart Hildebrand , Jarvis Roach Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" The IAR0/IAR1 register is used to acknowledge an interrupt - a read of the register activates the highest priority pending interrupt and provides its interrupt ID. Activating an interrupt can change the CPU's virtual interrupt state - this change makes sure the virtual irq state is updated. Signed-off-by: Jeff Kubascik Reviewed-by: Philippe Mathieu-Daud=C3=A9 --- Hello, I am using the ARMv8 version of QEMU configured with the gicv3 interrupt controller to run the Xen hypervisor with RTEMS as a guest VM (AArch32). I have noticed that when Xen injects a virtual irq to the guest VM, the guest gets stuck in the interrupt handler. The guest's interrupt handler does the following in order: - Reads IAR1 to acknowledge the interrupt and get the INTID - Unmasks interrupts by clearing the I bit in the CPSR register - Dispatches the interrupt to the appropriate driver - Restores the I bit in the CPSR state - Writes the INTID to EOIR1 to drop priority and deactivate the interrupt However, when the I bit was cleared, QEMU immediately raised the same virtual interrupt again. This process repeated itself indefinitely. The read of the IAR1 register should activate the interrupt and prevent it from firing again. However, the gicv3 device code wasn't updating the irq_line_state, so the CPU_INTERRUPT_VIRQ flag remained set. Therefore, when I bit was cleared, the CPU immediately switched to the exception handler. I have tested this patch, and it works for Xen with both an AArch64 Linux guest and an AArch32 RTEMS guest. Sincerely, Jeff Kubascik --- hw/intc/arm_gicv3_cpuif.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/hw/intc/arm_gicv3_cpuif.c b/hw/intc/arm_gicv3_cpuif.c index a254b0ce87..08e000e33c 100644 --- a/hw/intc/arm_gicv3_cpuif.c +++ b/hw/intc/arm_gicv3_cpuif.c @@ -664,6 +664,9 @@ static uint64_t icv_iar_read(CPUARMState *env, const AR= MCPRegInfo *ri) =20 trace_gicv3_icv_iar_read(ri->crm =3D=3D 8 ? 0 : 1, gicv3_redist_affid(cs), intid); + + gicv3_cpuif_virt_update(cs); + return intid; } =20 --=20 2.17.1