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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 39620C433EF for ; Tue, 10 May 2022 10:28:34 +0000 (UTC) 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:MIME-Version:References:In-Reply-To: Subject:Cc:To:From:Message-ID:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=oAV/LsHDot3HWp+EFXk6hyyy6Iq6HAE7h2hcfdarHog=; b=3LbihweHh3CHTl jxs/wzn3lhGjLP9WITXbSw5zEv0cMD8695fgE2Q6Jazq6I3h6j2hK1R0Xaio1l0zb00rNBiBme53c RsVDjht5HonJEpzGozPTcJk1FNEMZK7p9DPoHCZ7qRXxnAX0Sb0exQgTCnsvj8AB4ZwUJndqceXGK Pr7V45V3nQP+5NXDr6q5IjpAa0ucTIp5Jpe0HbbFJ0OOSDIcthDCSOY1U1UMq7Blu+33SUerbRUSW x4+UmRUxI0lr0kbhxhzuhUsTkyUOcjJugwVoUzuB0k+e3aDrYXurb7CEfG3e7A9EAC6pv+7VqVDxx mc2CbH3FQSFW80SibdBg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1noN5R-001BSX-Q8; Tue, 10 May 2022 10:27:25 +0000 Received: from ams.source.kernel.org ([2604:1380:4601:e00::1]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1noN5O-001BNv-Pp; Tue, 10 May 2022 10:27:24 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 27184B81CAD; Tue, 10 May 2022 10:27:21 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id DB895C385A6; Tue, 10 May 2022 10:27:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1652178439; bh=DpulMq7NLXNXeyCY5VjzmNzXxDP77EwqYOXUI+qi1hg=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=ogb8WjIvnhj/dPk7gypMy5omoJJwrF9bfL+wgnkJq485qyDA86EqWlIn69FYZdUqk wuh/gIKHbHpC3cy8at/Rn1L36Bctmb4UqsFsquEGuMkwlV/0jVpw+xwW241apzcyni mRWUQrEiCiJVtfRrPbArJcxt6s79ed2Y/uoMxui6q3p5ygZDlmXB72dSVGr6X10DBV c2YVIgZ9/Y/mpgGBBCK1ctcpc0YwOuDBzfKiP8bRakJzd6j0YjEALmnbUvvJINeny6 xdoZORcBIkYyjYPWBJNG5ZBPC5zlLJ+0F4LY31Iy5+MGHvWiBWk4xV7zr0A3SZ9lG2 uGeDjOXfsREqA== 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 1noN5J-00ACxh-Fm; Tue, 10 May 2022 11:27:17 +0100 Date: Tue, 10 May 2022 11:27:17 +0100 Message-ID: <87a6bp7ke2.wl-maz@kernel.org> From: Marc Zyngier To: Samuel Holland Cc: Thomas Gleixner , Palmer Dabbelt , Paul Walmsley , Albert Ou , Florian Fainelli , Guo Ren , Linus Walleij , Mark Rutland , Russell King , Wei Xu , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org Subject: Re: [PATCH 5/5] irqchip/sifive-plic: Separate the enable and mask operations In-Reply-To: <20220509034333.60017-6-samuel@sholland.org> References: <20220509034333.60017-1-samuel@sholland.org> <20220509034333.60017-6-samuel@sholland.org> 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") X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: samuel@sholland.org, tglx@linutronix.de, palmer@dabbelt.com, paul.walmsley@sifive.com, aou@eecs.berkeley.edu, f.fainelli@gmail.com, guoren@kernel.org, linus.walleij@linaro.org, mark.rutland@arm.com, linux@armlinux.org.uk, xuwei5@hisilicon.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220510_032723_171143_DCF2E982 X-CRM114-Status: GOOD ( 28.69 ) 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 Mon, 09 May 2022 04:43:33 +0100, Samuel Holland wrote: > > The PLIC has two per-IRQ checks before sending an IRQ to a hart context. > First, it checks that the IRQ's priority is nonzero. Then, it checks > that the enable bit is set for that combination of IRQ and context. > > Currently, the PLIC driver sets both the priority value and the enable > bit in its (un)mask operations. However, modifying the enable bit is > problematic for two reasons: > 1) The enable bits are packed, so changes are not atomic and require > taking a spinlock. > 2) The following requirememnt from the PLIC spec, which explains the > racy (un)mask operations in plic_irq_eoi(): > > If the completion ID does not match an interrupt source > that is currently enabled for the target, the completion > is silently ignored. > > Both of these problems are solved by using the priority value to mask > IRQs. Each IRQ has a separate priority register, so writing the priority > value is atomic. And since the enable bit remains set while an IRQ is > masked, the EOI operation works normally. The enable bits are still used > to control the IRQ's affinity. This is pretty neat. My only concern is around whether implementations do when changing priority of enabled interrupts. The PLIC architecture is conveniently silent on the subject, but that's certainly something that can result in total crap with the ARM GICs, for example, because an implementation is free to apply this priority change on an already pending interrupt, or not. But the kernel really wants the interrupt to be masked once it tells the HW to do so. Could anyone please check the RTL for some common implementations? A way to avoid the above trouble (should it exist) would be to disable the interrupt when changing the priority, and then reenable it. You'd still get the simpler EOI, which is what you really want. Thanks, 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