From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-14.0 required=3.0 tests=BAYES_00,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 006F1C4338F for ; Thu, 12 Aug 2021 07:49:13 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id CDEAB6044F for ; Thu, 12 Aug 2021 07:49:12 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234733AbhHLHtg (ORCPT ); Thu, 12 Aug 2021 03:49:36 -0400 Received: from mail.kernel.org ([198.145.29.99]:59760 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232348AbhHLHtc (ORCPT ); Thu, 12 Aug 2021 03:49:32 -0400 Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 1EE1A6044F; Thu, 12 Aug 2021 07:49:08 +0000 (UTC) Received: from sofa.misterjones.org ([185.219.108.64] helo=why.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1mE5Sc-004Ukj-AH; Thu, 12 Aug 2021 08:49:06 +0100 Date: Thu, 12 Aug 2021 08:49:05 +0100 Message-ID: <87a6ln9k7i.wl-maz@kernel.org> From: Marc Zyngier To: Valentin Schneider Cc: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Thomas Gleixner , Lorenzo Pieralisi , Vincenzo Frascino Subject: Re: [PATCH v3 02/13] genirq: Define ack_irq() and eoi_irq() helpers In-Reply-To: <20210629125010.458872-3-valentin.schneider@arm.com> References: <20210629125010.458872-1-valentin.schneider@arm.com> <20210629125010.458872-3-valentin.schneider@arm.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: valentin.schneider@arm.com, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, tglx@linutronix.de, lorenzo.pieralisi@arm.com, vincenzo.frascino@arm.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 29 Jun 2021 13:49:59 +0100, Valentin Schneider wrote: > > The newly-added IRQCHIP_AUTOMASKS_FLOW flag requires some additional > bookkeeping around chip->{irq_ack, irq_eoi}() calls. Define wrappers around > those chip callbacks to drive the IRQD_IRQ_FLOW_MASKED state of an IRQ when > the chip has the IRQCHIP_AUTOMASKS_FLOW flag. > > Signed-off-by: Valentin Schneider > --- > kernel/irq/chip.c | 16 ++++++++++++++++ > kernel/irq/internals.h | 2 ++ > 2 files changed, 18 insertions(+) > > diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c > index 21a21baa1366..793dbd8307b9 100644 > --- a/kernel/irq/chip.c > +++ b/kernel/irq/chip.c > @@ -408,6 +408,22 @@ void irq_percpu_disable(struct irq_desc *desc, unsigned int cpu) > cpumask_clear_cpu(cpu, desc->percpu_enabled); > } > > +void ack_irq(struct irq_desc *desc) > +{ > + desc->irq_data.chip->irq_ack(&desc->irq_data); > + > + if (desc->irq_data.chip->flags & IRQCHIP_AUTOMASKS_FLOW) > + irq_state_set_flow_masked(desc); > +} > + > +void eoi_irq(struct irq_desc *desc) > +{ > + desc->irq_data.chip->irq_eoi(&desc->irq_data); > + > + if (desc->irq_data.chip->flags & IRQCHIP_AUTOMASKS_FLOW) > + irq_state_clr_flow_masked(desc); I just realised that this has a good chance to result in a mess with KVM, and specially the way we let the vGIC deactivate an interrupt directly from the guest, without any SW intervention (the magic HW bit in the LRs). With this, interrupts routed to a guest (such as the timers) will always have the IRQD_IRQ_FLOW_MASKED flag set, which will never be cleared. I wonder whether this have a chance to interact badly with mask/unmask, or with the rest of the flow... Thanks, M. -- Without deviation from the norm, progress is not possible.