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 89ACBC27C53 for ; Wed, 12 Jun 2024 18:17:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Type:MIME-Version: References:In-Reply-To:Subject:Cc:To:From:Message-ID:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=8zpu24HoN3651QqkAXbRHT9HRBCnF9p5XhvPRul83Fk=; b=3hkHFR3JwaXVkLyc5SAKlW0H7z hOxJ2nbwBXMpimKUnqeRSMdXzFnBtQLt/3aevwtJ7VfhyYbr/oG1MPo31tPzK2QCt2nI58Wd8o2r8 Mv/ovOWjNrSI7iDnueTvG5IW9PTPtFKNYENPIUIofAmETOeArF8wDsFPEru79vV28m5QUSPfksyu3 EpnQg4MaoaL20ztrSkzc14Et1iHWygYdtgN0ifvM9VIBo+vY3kHZPkRDJnPmsju7olfHZhK6Wzdya 69K9OZnFMO+UH+l72tvMRWYKB+OYtFQUJHVqGQepTPvRYk5pZlc1tY4It7J0vAUZyeIwCKIcNEtEl /Bkj3b5w==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sHSXM-0000000DgfN-01OB; Wed, 12 Jun 2024 18:17:32 +0000 Received: from dfw.source.kernel.org ([139.178.84.217]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sHSXJ-0000000DgeQ-1fhr for linux-arm-kernel@lists.infradead.org; Wed, 12 Jun 2024 18:17:30 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 5CB42614BD; Wed, 12 Jun 2024 18:17:28 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 081ADC32786; Wed, 12 Jun 2024 18:17:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1718216248; bh=iR8vovlnxgSdFWuR1RMNpwzn1MV4P9geAj9vdcdOV8Q=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=GWRzxw7KESTLeEzC40fqZo7RPXPUIm8aqtdRMafKG/aFM6ZLSUfw2291lArC7ABSL n1T3xHPGhmhXqCo/Ox4KeM3/ezuUkSb3cF/bnc9eGXp5zM8nTKZ1lNyt7M7lh5Pb67 ncODo1+CsrSwIW/ge+LcDYH3LCtxRysTJsYS97O8fG9H/lU/JoSdR3MvaCbMRFlpc0 fk5cYkMH858JwckfafUsPI6sfJrFxpGLUI2Du4l1qdTwU1HeV8Tpltlu+2rYISQPnd cds0CSgn+Q2KJctto1TXDrxUQC1+ksBKaVqdn5qW6E4a1k7pc2ZW1kxt2u9yEsnwqR PPQA8aoQgXyxQ== 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 1sHSXF-003HJx-QR; Wed, 12 Jun 2024 19:17:25 +0100 Date: Wed, 12 Jun 2024 19:17:25 +0100 Message-ID: <861q52koui.wl-maz@kernel.org> From: Marc Zyngier To: Mark Rutland Cc: linux-arm-kernel@lists.infradead.org, alexandru.elisei@arm.com, catalin.marinas@arm.com, will@kernel.org Subject: Re: [PATCH 0/4] irqchip/gic-v3: use compiletime constant PMR values In-Reply-To: <20240529172116.1313498-1-mark.rutland@arm.com> References: <20240529172116.1313498-1-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/29.2 (aarch64-unknown-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: mark.rutland@arm.com, linux-arm-kernel@lists.infradead.org, alexandru.elisei@arm.com, 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-20240612_111729_587118_3EF45CAE X-CRM114-Status: GOOD ( 38.04 ) 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: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, 29 May 2024 18:21:12 +0100, Mark Rutland wrote: > > The GIC distributor and PMR/RPR can present different views of the > interrupt priority space dependent upon the values of GICD_CTLR.DS and > SCR_EL3.FIQ. Currently we treat the distributor's view of the priority > space as canonical, and when the two differ we change the way we handle > values in the PMR/RPR, using the `gic_nonsecure_priorities` static key > to decide what to do. > > This approach works, but it's sub-optimal. When using pseudo-NMI we > manipulate the distributor rarely, and we manipulate the PMR/RPR > registers very frequently in code spread out throughout the kernel (e.g. > local_irq_{save,restore}()). It would be nicer if we could use fixed > values for the PMR/RPR, and dynamically choose the values programmed > into the distributor. > > This series reworks the GIC code (and a small part of arm64 architecture > code) to allow the use of compiletime-constant PMR values. This > simplifies the logic for PMR management, and when using pseudo-NMI this > results in smaller and better generates code for saving/restoring the > irqflags, saving ~4K of text for defconfig + CONFIG_PSEUDO_NMI=y. > > The first patch is a preparatory cleanup which I think makes sense > regardlesss of the rest of the series. The second and third patches > rework the GICv3 code to be able to choose priorities at boot time, and > the final patch makes the actual switch. > > I've given this some light testing atop v6.10-rc1 with pseudo-NMI > enabled (with priority debugging), along with lockdep on the following > systems: > > * M1SDP Morello board, bare metal > Where GICD_CTRL.DS=0, SCR_EL3.FIQ=0 > Using shifted (NS) values in the distributor > > * M1SDP Morello board, KVM guest > Where GICD_CTRL.DS=1, SCR_EL3.FIQ=0 > Using unshifted values in the distributor > > * ThunderX2, KVM guest > Where GICD_CTRL.DS=1, SCR_EL3.FIQ=0 > Using unshifted values in the distributor > > On ThunderX2 bare-metal there is an existing boot-time hang when using > pseudo-NMI which is not solved by this series. With this seires applied, > the logging added in patch 3 reports that GICD_CTRL.DS=1, SCR_EL3.FIQ=0, > and so this should be using the same priorities which are seem to work > in a guest. It is pretty odd that bare metal reports DS=1+FIQ=0, as if it didn't have a secure side (and I'm pretty sure TX2 does). I wonder if that's only the distributor lying about security being disabled. Note that a another issue exists with the original ThunderX, where while the HW reports: GICv3: GICD_CTRL.DS=0, SCR_EL3.FIQ=1 the machine locks up with RCU stalls. Similarly, this is independent of this series being applied or not. But ThunderX has so many bugs and warts that I'm definitely not losing any sleep over it. However, it works well on my Synquacer, which is reassuring. > > Mark. > > Mark Rutland (4): > irqchip/gic-common: remove sync_access callback > irqchip/gic-v3: make distributor priorities variables > irqchip/gic-v3: detect GICD_CTRL.DS and SCR_EL3.FIQ earlier > irqchip/gic-v3: select priorities at boot time > > arch/arm64/include/asm/arch_gicv3.h | 15 -- > arch/arm64/include/asm/ptrace.h | 35 +--- > arch/arm64/kernel/image-vars.h | 5 - > drivers/irqchip/irq-gic-common.c | 22 +-- > drivers/irqchip/irq-gic-common.h | 7 +- > drivers/irqchip/irq-gic-v3-its.c | 11 +- > drivers/irqchip/irq-gic-v3.c | 225 ++++++++++++------------ > drivers/irqchip/irq-gic.c | 10 +- > drivers/irqchip/irq-hip04.c | 6 +- > include/linux/irqchip/arm-gic-common.h | 4 - > include/linux/irqchip/arm-gic-v3-prio.h | 52 ++++++ > include/linux/irqchip/arm-gic-v3.h | 2 +- > 12 files changed, 193 insertions(+), 201 deletions(-) > create mode 100644 include/linux/irqchip/arm-gic-v3-prio.h For the series: Reviewed-by: Marc Zyngier Tested-by: Marc Zyngier Given that this touches some pretty deep aspects of the arm64 code, I think this should go via the arm64 tree, but I'll let you work that one out (you may want to Cc LKML and tglx though). Thanks, M. -- Without deviation from the norm, progress is not possible.