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 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id DC624C433EF for ; Wed, 17 Nov 2021 10:18:39 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 6B3C96127C for ; Wed, 17 Nov 2021 10:18:39 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 6B3C96127C Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=R+Sf0yfjaBLy0nRMAPUYA+LzT9Q4vBuTmYJjyI5H8zQ=; b=qWEu8+c6+wVFk2 jGCNPQJjefJar1gV7n2x8HSdFytAorPMikmwv8uhgIf2SxiLtMtPB6MCrubkiWFFx38kWe99H9XOl geJJu/Z/a4K6jPFhxooUZNnUmtMLYmcWoRH7kTzdLg0RuA3ompZZYvKKdgXEkG/zs8FsZmGvYkPIj oz0aLLKXZ6l9zRJxpoOYJvjECDAoDKPWmhIv6mtSRjAHPECMvy8LPQWZwSrJSqFnpvhBv1BNe2XqS NtomZ9+RioorFslTcLKYBdVi8rs82cd6nWJ5BOPiOXVDYJL9YfZixQdLHzbibGUD4WUPHoSCaO9OZ EhQt4z0ecfF6hudrBy6Q==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mnI01-004Pzo-M6; Wed, 17 Nov 2021 10:17:05 +0000 Received: from mail-pf1-x42a.google.com ([2607:f8b0:4864:20::42a]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mnHzy-004PzU-Bl for linux-arm-kernel@lists.infradead.org; Wed, 17 Nov 2021 10:17:04 +0000 Received: by mail-pf1-x42a.google.com with SMTP id x5so2259631pfr.0 for ; Wed, 17 Nov 2021 02:17:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=3pxJ3oQB88Hy6nnUYDAPmtV0wGKDywu1tvGr37CcGmo=; b=AZ/Y9d/NSXMTpaI2z25ku/RMHoWjo3mZ+y8XHxGQ5jbIZKDm7g4blxLcUiMWLvIlpm wGUwYxmaUS1OAy2cMZkJHKpEWLk9ToHgLsLt3CR+zMndDWPJAyDHrB2KZY6R76n3puHG 3hyA2650ItEozwaqN45clgDPsve++NhxBKu19joIc1zlPoLyt9MuYtUblJGSsAQoSiBx OvUQHpusTitQKVdppwvSd9jXW70HXIF6oMYATXLFMQBcQHuNKVeoSy2yYJ6an0FO8Hsx zNdCalG/WoWw2GkY+ZL7zIzruruuWjXVC7JV4wPma7N0w0lA1Omgp0ZurtSaGAN3yWyq ImXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=3pxJ3oQB88Hy6nnUYDAPmtV0wGKDywu1tvGr37CcGmo=; b=dP+ararYkpd5z+saVUojw77Co/XY6F4ZeuHofUkbd+D+ayKCKPiQhROp7rdipf84OC FgHM4wcPRw/Lzvh9qRrMvC0a+PHq9J8fBgjeEm+SddiPgcyxxvBhlPP16Ipka4TGs8Zc B/vgiNfc1Vcte1gb7XilbelOZv9vjwro4eXcy1TGPCbUSA93YGVx8K1Eur0xjrRyYJQM HMgHGE1kYv2TXGBa3/84nSn7k3GSFj86Fv+FLTjU/LNBnRO2+cmTZ0s7F6pvkXXp8snj qpB0HTNKjE/MtRc55O95iytm8FxezvRxqO8UKXQvYNeU2yDfNsdTuyIBjeYJCjjNb8X/ YotA== X-Gm-Message-State: AOAM5306K/1xKoVVd2DlTYL3jOw4XUIVS+v/Eqbq9Qjjc3paajXmnfih 9z40OOKYNIFdQWf+4DDIcA== X-Google-Smtp-Source: ABdhPJxZlFb6Flfdv48dXZtqAXEASsgD+al8cdIwbO46Q3dKugeyWyPZohgqhH4U7kYuIEhZZSlgaA== X-Received: by 2002:a63:5642:: with SMTP id g2mr4438997pgm.152.1637144220621; Wed, 17 Nov 2021 02:17:00 -0800 (PST) Received: from piliu.users.ipa.redhat.com ([209.132.188.80]) by smtp.gmail.com with ESMTPSA id f4sm20991170pfg.34.2021.11.17.02.16.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 17 Nov 2021 02:17:00 -0800 (PST) Date: Wed, 17 Nov 2021 18:16:53 +0800 From: Pingfan Liu To: Marc Zyngier Cc: linux-arm-kernel@lists.infradead.org, Catalin Marinas , Will Deacon , Mark Rutland , Joey Gouly , Sami Tolvanen , Julien Thierry , Yuichi Ito , rcu@vger.kernel.org Subject: Re: [PATCHv3 3/4] irqchip: GICv3: expose pNMI discriminator Message-ID: References: <20211116082450.10357-1-kernelfans@gmail.com> <20211116082450.10357-4-kernelfans@gmail.com> <878rxo8m0a.wl-maz@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <878rxo8m0a.wl-maz@kernel.org> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20211117_021702_453224_BDE1A517 X-CRM114-Status: GOOD ( 37.18 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, Nov 16, 2021 at 09:53:25AM +0000, Marc Zyngier wrote: > Hi Pingfan, > > On Tue, 16 Nov 2021 08:24:49 +0000, > Pingfan Liu wrote: > > > > Arch level code is ready to take over the nmi_enter()/nmi_exit() > > housekeeping. > > > > GICv3 can expose the pNMI discriminator, then simply remove the > > housekeeping. > > > > Signed-off-by: Pingfan Liu > > Cc: Catalin Marinas > > Cc: Will Deacon > > Cc: Mark Rutland > > Cc: Marc Zyngier > > Cc: Joey Gouly > > Cc: Sami Tolvanen > > Cc: Julien Thierry > > Cc: Yuichi Ito > > Cc: rcu@vger.kernel.org > > To: linux-arm-kernel@lists.infradead.org > > --- > > drivers/irqchip/irq-gic-v3.c | 18 ++++++++++++------ > > 1 file changed, 12 insertions(+), 6 deletions(-) > > > > diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c > > index daec3309b014..aa2bcb47b47e 100644 > > --- a/drivers/irqchip/irq-gic-v3.c > > +++ b/drivers/irqchip/irq-gic-v3.c > > @@ -646,12 +646,8 @@ static void gic_deactivate_unhandled(u32 irqnr) > > > > static inline void gic_handle_nmi(u32 irqnr, struct pt_regs *regs) > > { > > - bool irqs_enabled = interrupts_enabled(regs); > > int err; > > > > - if (irqs_enabled) > > - nmi_enter(); > > - > > if (static_branch_likely(&supports_deactivate_key)) > > gic_write_eoir(irqnr); > > /* > > @@ -664,8 +660,6 @@ static inline void gic_handle_nmi(u32 irqnr, struct pt_regs *regs) > > if (err) > > gic_deactivate_unhandled(irqnr); > > > > - if (irqs_enabled) > > - nmi_exit(); > > } > > > > static u32 do_read_iar(struct pt_regs *regs) > > @@ -702,6 +696,15 @@ static u32 do_read_iar(struct pt_regs *regs) > > return iar; > > } > > > > +static bool gic_is_in_nmi(void) > > +{ > > + if (gic_supports_nmi() && > > + unlikely(gic_read_rpr() == GICD_INT_RPR_PRI(GICD_INT_NMI_PRI))) > > + return true; > > I don't think this fixes anything. > > RPR stands for 'Running Priority Register', which in GIC speak reports > the priority of the most recently Ack'ed interrupt. > > You cannot use this to find out whether the interrupt that you /will/ > ack is a NMI or not. Actually, you cannot find out about *any* > priority until you actually ack the interrupt. What you are asking for > is the equivalent of a crystal ball, and we're in short supply... ;-) > > The only case where ICC_RPR_EL1 will return something that is equal to > GICD_INT_NMI_PRI is when you are *already* in an NMI context. So > unless I have completely misunderstood your approach (which is always > possible), I don't see how this can work. > Thank you for the clear explanation. Also I revist this part in "GIC v3 and v4 overview" and have a deeper understanding. (Need to spare time to go through all later) You totally got my idea, and I need to find a bail-out. As all kinds of PIC at least have two parts of functions: active (Ack) and deactive(EOI), is it possible to split handle_arch_irq into two parts? I.e let irqchip expose two interfaces: u32 (*read_irqinfo*)(struct pt_regs *regs, bool *is_nmi) void (*handle_arch_irq)(struct pt_regs *regs, u32 irqnr) to replace the current interface: void (*handle_arch_irq)(struct pt_regs *regs) I have thought about such stuff for some days. And the benefits include: -1. For this bugfix (by the parameter 'is_nmi') -2. IPI_RESCHEDULE performance drop issue can be resolved at arch code level. (by irqnr - ipi_irq_base == IPI_RESCHEDULE ?) -3. The arch level can provide a similar loop as aic_handle_irq() in irq-apple-aic.c, which can save cpu by avoiding heavy context sync when irq is intensive. Do you think it is doable? Thanks, Pingfan > If you want to distinguish between NMI and IRQ early on (before > acknowledging the interrupt), the only solution is to turn the NMI > into a Group-0 interrupt so that it is presented to the CPU as a > FIQ. At which point, you have the information by construction. > > Unfortunately, this will only work in VMs, as Group-0 interrupts are > usually routed to EL3 on bare metal systems. > > M. > > -- > Without deviation from the norm, progress is not possible. > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel