From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9E24F606A31B for ; Tue, 27 Oct 2026 09:42:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key, unprotected) header.d=lists.infradead.org header.i=@lists.infradead.org header.a=rsa-sha256 header.s=bombadil.20210309 header.b=g9vN0PzB; dkim=pass (2048-bit key, unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=VEm0MPZl 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-Unsubscribe-Post:List-Owner; bh=GurZx2Ho4AP54wrDDZb5G/1lKP+4oYBqF+5vJ2smE3o=; b=g9vN0PzBwJtDyDpc/AalmDx+BM cOEE/LYFrle/I7+oURqDn6MjFkSWkRSY6O29lTFOormsMlOz1VHSMr9zuT8saKuSPZgJEVIV02ssj HcFjSgStofafCBmwnbKlrFC9tdKGu++azakQc0SQWZzDrLpN4PEukpZnysUUr6G1tJ2MyKsR4gFYE OiliXv44fCVY0IHVwrvVPeTNUZiN9xdvuQ0ftKy+S/dQhckJV/XM/NYeVvgCE9VUlsdUiws7wNwVV m39mQvDdHxu9UYm/Svx7wzvRpijV8c/oWann0GPbYDbBAAotyPTcQLjIbT0lhqcjVZK0LsZwom9nb 6y9xcefw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.100.1 #2 (Red Hat Linux)) id 1xLdhY-00000004CFa-3k88; Tue, 27 Oct 2026 09:42:40 +0000 Received: from tor.source.kernel.org ([172.105.4.254]) by bombadil.infradead.org with esmtps (Exim 4.100.1 #2 (Red Hat Linux)) id 1xLdhY-00000004CFP-0sPy for linux-arm-kernel@lists.infradead.org; Tue, 27 Oct 2026 09:42:40 +0000 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by tor.source.kernel.org (Postfix) with ESMTP id A4CB260211; Tue, 27 Oct 2026 09:42:39 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 57B431F01825; Tue, 27 Oct 2026 09:42:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1793094159; bh=GurZx2Ho4AP54wrDDZb5G/1lKP+4oYBqF+5vJ2smE3o=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=VEm0MPZlRxdNbDc5r6bGXV9SKgZULsCF6g0uioIs/k3MEjQt+nLr4j6/Rm94zevQK FuB56jiJYaB1qGq5EYrKI2ZWYfejAK+xuhran4QqIipAr5UACILTzsU7k4FCDGaaCp eZidDLnc7Awln6YkmOz1O8whvZFdtEWPjFVnBvOqhsokCIUUmv7Pe/L1+xZFsqTT74 BJ7+599isU7tgMfftU0A1+QbAYmzBzJ0z/juRsQE1KoSjP5rUi0QH5XqMtn3j+dWgx wUwtX31cOi+NPlQzKYRzFCotSMRzvs2sKlnk9oeLtfPIhRoYo2NaWhGOf7/crl+uDf Y7swdRvKyfs/Q== 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.98.2) (envelope-from ) id 1xLdhV-00000007cqT-0fgC; Tue, 27 Oct 2026 09:42:37 +0000 Date: Tue, 27 Oct 2026 09:42:36 +0000 Message-ID: <86v76nxywj.wl-maz@kernel.org> From: Marc Zyngier To: Ashok Raj Cc: Vladimir Murzin , linux-arm-kernel@lists.infradead.org, catalin.marinas@arm.com, will@kernel.org, mark.rutland@arm.com, lpieralisi@kernel.org, ruanjinjie@huawei.com, liaochang1@huawei.com, Ashok Raj , Jonathan Cameron , Jonathan Cameron Subject: Re: [PATCH 00/38] arm64: Add support for FEAT_NMI In-Reply-To: References: <20260914102102.68597-1-vladimir.murzin@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/30.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) X-Archived-By: 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: ashok.raj@oss.qualcomm.com, vladimir.murzin@arm.com, linux-arm-kernel@lists.infradead.org, catalin.marinas@arm.com, will@kernel.org, mark.rutland@arm.com, lpieralisi@kernel.org, ruanjinjie@huawei.com, liaochang1@huawei.com, ashoraj@qti.qualcomm.com, jic23@kernel.org, jonathan.cameron@oss.qualcomm.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" X-Spam-Status: No, score=-11.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=4.0.1 X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on aws-us-west-2-korg-listserv-alma10-1 On Mon, 26 Oct 2026 19:25:21 +0000, Ashok Raj wrote: > > On Fri, Oct 23, 2026 at 09:20:16PM -0700, Ashok Raj wrote: > > On Mon, Sep 14, 2026 at 11:20:24AM +0100, Vladimir Murzin wrote: > > > > > FEAT_NMI provides an architected mechanism for supporting non-maskable > > > interrupts (NMIs) and less-masked interrupts (LMIs). > > > > > > Since we already support pseudo-NMIs via priority masking, introducing > > > another flavour of NMI on top of the existing infrastructure could > > > easily become messy, making the code harder to follow and reason > > > about. > > > > > > To avoid that, this series first makes room for the new NMI "tenant" > > > by restructuring the existing exception masking logic (patches 01/38 - > > > 15/38) > > > > > > Hi all, > > > > I am working on arm64 HEST/GHES Type-4 (NMI) support using FEAT_NMI > > and GIC NMI support. > > > FYI: I have submitted a code-first proposal for the Type-4 HEST/GHES > changes. > > I have some internal things to iron out to submit directly, thanks to > Jonathan for helping out in the review and upload the document. > > > https://github.com/tianocore/edk2/issues/13392 > > I have patches to work with this on top of the latest posted FEAT_NMI > series all tested on Qemu SBSA ref. Will post them in a bit. > > Please help with the review. I strongly oppose this sort of hacks. Priorities (and by extension NMIs) only make sense when in the context of the full set of priorities that the operating system uses. The fact that Linux doesn't make much use of priorities should not result in the firmware table becoming prescriptive. The piece of SW that deals with the interrupt source should have enough information to decide whether it is worth assigning a higher priority to that interrupt, and there is no extra information to convey. If the firmware table doesn't describe in enough detail what that interrupt is for, then by any mean add that. But mandating that the OS messes up its own priority scheme for $ARBITRARY_REASONS is not an acceptable outcome. Thanks, M. -- Without deviation from the norm, progress is not possible.