From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C24823BFE4F for ; Wed, 20 May 2026 09:20:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779268818; cv=none; b=mbFe6fxhERAjz7zm+aB8kAO393VS+QtVWgQhi7K2xP3CQwcrKQTROfKEu4kcJUdSvhvwu5Evy6ThqNY42mQtj20vEiCsZUcIh6FLbvN5bexo5q9pAr/yzIRNfBLp4Eqx2P/cmd7omjejPWqSXaew3j5dQDY8pn9szVXkEnfhxeQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779268818; c=relaxed/simple; bh=IXwtASoWr0Rh5sMg1W1zwBg/xgjbLHcI6sW2VMPX6cY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=AKQQDX185xFy+HjQmYP/FERb13d5QylfalbJDVInatF5gspP6FglvQpi+T2UVywsbgNu60MI75bnIL6V9NgBSqmVo/UuFcwIBZqWC8ilvQ8K3+6vzU17aMrCOTy89UOySOOyqbFZh7/iNn3bq7+MxGG280bz4bT4RIqIMNKYbtA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=QIDqcAsw; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="QIDqcAsw" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 70D5C1F008A1; Wed, 20 May 2026 09:20:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1779268815; bh=0mXUR6fwEd+l0SmGEm+HWa6PfAmUsYcC1//bGnZmKVY=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=QIDqcAswcpESA1hmA6kPG7ccYMskjvulaWm+lF8WUGo6JVbJcC+LJB4oOUv5/jG+v oeGI70RchhQnUk3yGdblNB3FVftzTx6+ish3Kf0Qr1I0CbulkmU6gvamzmYXSg6fQH 9MMmA32G5rqn23oGc6nid+vRWv3jKDBuA7w/rEf5aEv8TYtOoACZnnUxPyICF3MBD0 VfcAoZlIlTRkWhI5hdul0fxNSP0EJGwJxrWQLe97GNZvCqJ5e75b4X28oOxdNVSBYC nN3LfUemfvKEKM5y0a04JuFRd/00K086MiTJ4RvpzlmAFepVJZUL00Kem93CgSe9pZ tAFytX/GcSekA== Received: from sofa.misterjones.org ([185.219.108.64] helo=valley-girl.lan) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1wPd65-00000004IaV-3DvB; Wed, 20 May 2026 09:20:13 +0000 From: Marc Zyngier To: kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org Cc: Steffen Eiden , Joey Gouly , Suzuki K Poulose , Oliver Upton , Zenghui Yu , Sascha Bischoff Subject: [PATCH v2 17/18] irqchip/gic-v5: Immediately exec priority drop following activate Date: Wed, 20 May 2026 10:19:48 +0100 Message-ID: <20260520091949.542365-18-maz@kernel.org> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20260520091949.542365-1-maz@kernel.org> References: <20260520091949.542365-1-maz@kernel.org> Precedence: bulk X-Mailing-List: kvmarm@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, seiden@linux.ibm.com, joey.gouly@arm.com, suzuki.poulose@arm.com, oupton@kernel.org, yuzenghui@huawei.com, sascha.bischoff@arm.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false From: Sascha Bischoff With GICv5 an interrupt of equal or lower priority cannot be signalled until there has been a priority drop. This is done via the GIC CDEOI system instruction. Once this has been executed, the hardware is able to signal the next interrupt if there is one. As all interrupts are programmed to have the same priority, no new interrupts can be signalled until the priority drop has happened. This can cause issues when, for example, an interrupt remains active while a long running process takes place, such as when injecting a physical interrupt into a guest VM in software. The GICv5 driver has so far done the priority drop as part of irq_eoi(), i.e., at the same time as deactivating the interrupt. This means that any long running process (or VM) could block incoming interrupts, effectively causing a denial of service for all other interrupts. Rather than doing the EOI as part of irq_eoi() (which the name would suggest would be a good place for it), move it to happen immediately after acknowledging an interrupt in the main GICv5 interrupt handler. The deactivation of interrupts (GIC CDDI) remains implemented as part of irq_eoi(), which means that the same interrupt cannot be signalled a second time until deactivated by software. Suggested-by: Marc Zyngier Signed-off-by: Sascha Bischoff Signed-off-by: Marc Zyngier --- drivers/irqchip/irq-gic-v5.c | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/drivers/irqchip/irq-gic-v5.c b/drivers/irqchip/irq-gic-v5.c index 6b0903be8ebfd..58e457d4c1476 100644 --- a/drivers/irqchip/irq-gic-v5.c +++ b/drivers/irqchip/irq-gic-v5.c @@ -218,17 +218,13 @@ static void gicv5_hwirq_eoi(u32 hwirq_id, u8 hwirq_type) FIELD_PREP(GICV5_GIC_CDDI_TYPE_MASK, hwirq_type); gic_insn(cddi, CDDI); - - gic_insn(0, CDEOI); } static void gicv5_ppi_irq_eoi(struct irq_data *d) { /* Skip deactivate for forwarded PPI interrupts */ - if (irqd_is_forwarded_to_vcpu(d)) { - gic_insn(0, CDEOI); + if (irqd_is_forwarded_to_vcpu(d)) return; - } gicv5_hwirq_eoi(d->hwirq, GICV5_HWIRQ_TYPE_PPI); } @@ -963,6 +959,13 @@ static void __exception_irq_entry gicv5_handle_irq(struct pt_regs *regs) */ isb(); + /* + * Ensure that we can receive the next interrupts in the event that we + * have a long running handler or directly enter a guest by doing the + * priority drop immediately. + */ + gic_insn(0, CDEOI); + hwirq = FIELD_GET(GICV5_HWIRQ_INTID, ia); handle_irq_per_domain(hwirq); -- 2.47.3