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 30CF6C47089 for ; Wed, 7 Dec 2022 19:00:43 +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=aBtuQcSVMkIh2GK8s/ifuiTs1Dyql5HSJCoFaHvIV+Y=; b=r+pm+xRGrW/Vb7 7fl85Lq2JC44lXkna5M8MehuQ28cnLguHsdIG3MziLqMzFiuOeLhagupLnxQltBPfKW7OCRBksJoR PYndUvQ/BPHNm+TQ5TATKU4CY5gLO4Hy4EtoXYGelFbKcgC/3s6CV0kuYMWKi/B6gv3BIrWZQklCI Wm0i/a/2r9Ri43Tfzpq3WdEOzHeC9ZVums1MmFmEZ45YXLb2OV0UGoJ5NsMkQBlbX3wkr4/4L0r74 BwABFubWwdaSw8pq8MjXygA0MhnR7SeF61D4Pr3+gvCMTJ57V5XqX0EQSONCyqVa3CbhIx/XCy6p+ LYizRVFgPZhuvrccT/nw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1p2zdc-00A43r-37; Wed, 07 Dec 2022 18:59:24 +0000 Received: from ams.source.kernel.org ([145.40.68.75]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1p2zdY-00A3zH-Dk for linux-arm-kernel@lists.infradead.org; Wed, 07 Dec 2022 18:59:22 +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 F198BB82051; Wed, 7 Dec 2022 18:59:18 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A4372C433C1; Wed, 7 Dec 2022 18:59:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1670439557; bh=q5IRkPLLu04px3Kj8zsDJ2uN+/UfE/2v1ijrawcRo58=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=GT9crMBf9/Gxz7zZKNuxuSyUOn3h8pHx380oJCF1tUbVxwONhmndT9kSzqfwkTr2h gg3bMqT2mgcy0KpGnqnaMcRoVB1OjD84E/0cFe4nU+QfaX+M9pfJXHlTZJTyVgkcQF hI2gUYgmdCmMTwmJuLk+s4iPQFoTSAxPhy46vUJ6WbaMuWfbNs5zrf5L8Ii2lc5w4F yNeC0QdqruEg2wgWXkh8BIV1jrIJTtUTbxb9MFAQQW/zKnHbF8u4N8uhsGPA9QgOtU FD8kC72Hd5vYT3iu3T6APGXY6X+wal6bYwZkGqrCZ2cfEkFmabK3XaoZR+LJJgQ3iK 0vxWEtYv01zSg== Received: from ip-185-104-136-29.ptr.icomera.net ([185.104.136.29] helo=wait-a-minute.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 1p2zdS-00BBeR-TE; Wed, 07 Dec 2022 18:59:15 +0000 Date: Wed, 07 Dec 2022 18:57:32 +0000 Message-ID: <87zgbzrqhv.wl-maz@kernel.org> From: Marc Zyngier To: Mark Brown Cc: Catalin Marinas , Will Deacon , Lorenzo Pieralisi , Mark Rutland , Sami Mujawar , Thomas Gleixner , linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev Subject: Re: [PATCH v2 12/14] arm64/nmi: Add handling of superpriority interrupts as NMIs In-Reply-To: References: <20221112151708.175147-1-broonie@kernel.org> <20221112151708.175147-13-broonie@kernel.org> <86k033lblt.wl-maz@kernel.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.104.136.29 X-SA-Exim-Rcpt-To: broonie@kernel.org, catalin.marinas@arm.com, will@kernel.org, lpieralisi@kernel.org, mark.rutland@arm.com, Sami.Mujawar@arm.com, tglx@linutronix.de, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev 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-20221207_105920_788798_F2B07504 X-CRM114-Status: GOOD ( 35.00 ) 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 Wed, 07 Dec 2022 13:24:19 +0000, Mark Brown wrote: > > On Wed, Dec 07, 2022 at 11:03:26AM +0000, Marc Zyngier wrote: > > Mark Brown wrote: > > > > +int set_handle_nmi_irq(void (*handle_irq)(struct pt_regs *)); > > > +int set_handle_nmi_fiq(void (*handle_fiq)(struct pt_regs *)); > > > I'm not overly keen on adding hooks that are not used, and I can't > > really foresee a use case for a FIQ NMI at the moment (there is no > > plan to use Group-0 interrupts in VMs when the GIC is enabled, and the > > only interrupt controller we have that uses FIQ doesn't even have > > priorities, let alone NMIs). > > Sure, I don't care either way - I wasn't sure if people would prefer > symmetry/completeness or minimal usage so took a guess. I did consider > that the FIQ user might decide to implement NMIs on the basis that > they're easier to use than priorities but it's five minutes work to add > the API back when needed if that does happen. The FIQ user doesn't even have such concept in the interrupt controller, nor does it have the corresponding CPU feature. Let's keep it minimal for now. As you said, bringing it back is pretty easy. > > > > + /* > > > + * Any system with FEAT_NMI should not be > > > + * affected by Spectre v2 so we don't mitigate > > > + * here. > > > + */ > > > Why? I don't see a good reason not to mitigate it, specially when the > > mitigation is guarded by cpus_have_const_cap(ARM64_SPECTRE_V2). Maybe > > you can explain what the rationale is for this. > > Any CPU new enough to have FEAT_NMI is architecturally required to also > have FEAT_CSV2 since that's mandatory since v8.5 and FEAT_NMI is a v8.8 > feature. FEAT_CSV2 means the hardware doesn't need the mitigation, and > we check for it in spectre_v2_get_cpu_hw_mitigation_state(). I was > trying to thread the needle between doing it for a combination of > symmetry and defensive programming and people seeing that the test would > always be false and should therefore be removed, especially in a hot > path like this. "Hypothetically", CPUs that advertise CSV2 could subsequently be found to actually require extra handling, and I really wouldn't take such a bet. The reasoning by which CPU designers follow the ARM feature dependency rules doesn't hold any water either, and hasn't for years (ARM itself has been backporting features into CPUs that have a much older base architecture). You don't have to look very far to find implementations that cherry-pick whatever they want. The sad reality is that nobody gives a damn about this rule, and ultimately pick whatever they see fit. And given that this is only one static branch away, that the runtime cost is likely to be a big fat zero for non-affected platforms, for an event that is vanishingly rare anyway, I'd rather we stay consistent in the whole interrupt path and keep the mitigation code in. 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