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 89DB1C38142 for ; Mon, 23 Jan 2023 13:24:52 +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=T5Z6NGh+JXjG77BYivYnML9C/I9fjlOxFooqrkq9wzk=; b=bz1LVp3dkXH42F wLHlVpb9elc4xCt/4iLwFu1YRwOmmB64HgO9vlvdurXeDS5QuIG/AqRvHscPznim2ts4yhsg7YHHE USQdfnVtl5C+M8QTI3AVChkT2tG7h3HksmJYoth+8RvuFz1fvPWKla2HKDGVqMxNlUQ+4Q3THnBZE +49lW4BqqKS72y+NF59KDF/lt3x1/Aamj1t29ICvwqTLnR5+KtkIiraeUd2vAxJEGzajjsXmCqrI2 8UKr6AxNrygYJCGqRsgaFvHgQxVuYNB21Ojty7O69cVh8GmB9fCHZlPvM5cUrqypUr1KoXAQGqfMc mz5dgp1g/5Q3W1cJfaCQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1pJwnV-00HLrB-UR; Mon, 23 Jan 2023 13:23:42 +0000 Received: from dfw.source.kernel.org ([2604:1380:4641:c500::1]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1pJwnR-00HLqr-JM for linux-arm-kernel@lists.infradead.org; Mon, 23 Jan 2023 13:23:38 +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 dfw.source.kernel.org (Postfix) with ESMTPS id E2B7960EFF; Mon, 23 Jan 2023 13:23:35 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4A51AC433D2; Mon, 23 Jan 2023 13:23:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1674480215; bh=o97/sWqlQDuJMKp7MFEdqPjdwhtn967a1glsY3Uwco8=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=tj+S73A4YWM7f765jPJoZoTu9fmQ0S/d9qvi3fviCq5YsSRpCdGlWFOtIu/sYNBJt MrSyM9khnAtPU+mcgg5RvFL6BI3uzkCZlQHrK7Q42HVLdf8Lk41NQbrnOGMmDYSJuo LJi8ZFLDVKvVvdl70PvdWrAEZgErDk1lW0nosqEDQtb19uBtnERL6mgloC/70DjAmr yqz5vew1yPidinAPOfSEcW+MjPJUwF8vnPY+7OjGiFPECZPmlgrQKIKzitMQPkDf6A SDpysBqjWT+vmvVGhFvkBTiSvqDLUfP879V3zs8bEwIsbXtTAP8abLdjlePX1ue0PM 5i/Cf6F0LnjoQ== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1pJwnM-003x4h-9m; Mon, 23 Jan 2023 13:23:33 +0000 Date: Mon, 23 Jan 2023 13:23:31 +0000 Message-ID: <86bkmpmlkc.wl-maz@kernel.org> From: Marc Zyngier To: Mark Rutland Cc: linux-arm-kernel@lists.infradead.org, broonie@kernel.org, catalin.marinas@arm.com, will@kernel.org Subject: Re: [PATCH 3/4] arm64: add ARM64_HAS_GIC_PRIO_NO_PMHE cpucap In-Reply-To: <20230123124042.718743-4-mark.rutland@arm.com> References: <20230123124042.718743-1-mark.rutland@arm.com> <20230123124042.718743-4-mark.rutland@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/28.2 (aarch64-unknown-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: mark.rutland@arm.com, linux-arm-kernel@lists.infradead.org, broonie@kernel.org, catalin.marinas@arm.com, will@kernel.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-20230123_052337_750971_9CB0E5F8 X-CRM114-Status: GOOD ( 24.76 ) 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, 23 Jan 2023 12:40:41 +0000, Mark Rutland wrote: > > When Priority Mask Hint Enable (PMHE) == 0b1, the GIC may use the PMR > value to determine whether to signal an IRQ to a PE, and consequently > after a change to the PMR value, a DSB SY may be required to ensure that > interrupts are signalled to a CPU in finite time. When PMHE == 0b0, > interrupts are always signalled to the relevant PE, and all masking > occurs locally, without requiring a DSB SY. > > Since commit: > > f226650494c6aa87 ("arm64: Relax ICC_PMR_EL1 accesses when ICC_CTLR_EL1.PMHE is clear") > > ... we handle this dynamically: in most cases a static key is used to > determine whether to issue a DSB SY, but the entry code must read from > ICC_CTLR_EL1 as static keys aren't accessible from plain assembly. > > It would be much nicer to use an alternative instruction sequence for > the DSB, as this would avoid the need to read from ICC_CTLR_EL1 in the > entry code, and for most other code this will result in simpler code > generation with fewer instructions and fewer branches. > > This patch adds a new ARM64_HAS_GIC_PRIO_NO_PMHE cpucap which is only > set when ICC_CTLR_EL1.PMHE == 0b0 (and GIC priority masking is in use). > This allows us to replace the existing users of the `gic_pmr_sync` > static key with alternative sequences which default to a DSB SY and are > relaxed to a NOP when PMHE is not in use. I personally find the "negative capability" pretty annoying, specially considering that hardly anyone uses PMHE. The way the code reads with this patch, it is always some sort of double negation. Can't the DSB be patched-in instead, making the PMHE cap a "positive" one? It shouldn't affect interrupt distribution as long as the patching occurs before we take interrupts. For modules, the patching always occurs before we can run the module, so this should be equally safe. The patch otherwise looks OK to me. 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