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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 74D7FC433EF for ; Tue, 10 May 2022 10:27:30 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239826AbiEJKbY (ORCPT ); Tue, 10 May 2022 06:31:24 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39864 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239673AbiEJKbU (ORCPT ); Tue, 10 May 2022 06:31:20 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 585F61E3EFC for ; Tue, 10 May 2022 03:27:22 -0700 (PDT) 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 1BDA7B81CAA for ; 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") Content-Type: text/plain; charset=US-ASCII 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 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.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.